Gerald Fischer wrote:

> Hi Jose, hi Hackers!
>
> I reinstalled Postgresql with this patch about 10 times in the last 2 days, but without success. :-(
>
> I tried now to use the snapshot, and it compiled nearly without problems (in /src/interfaces/ecpg/preproc/preproc.y is a ';' missing on line 1562), but the ODBC-Driver can't connect to the database. The logfile
> says:
> ----------------
>

The snapshot is very unstable at this time.    6.4 will not be official until after Oct.1.   I would suggest not using it at this time

> ---------
> And with the snapshot of sept. 6th, it complains about a missing MSysConf-Table. :-(
> --------
> conn=71501948, query='declare SQL_CUR71516440 cursor for SELECT Config, nValue FROM MSysConf'
> ERROR from backend during send_query: 'ERROR:  msysconf: Table does not exist.'
> --------

This is a normal error.  MS Access always queries this table.  It is not necessary for successful processing.

>
>
> Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).
>

It is difficult for me to figure out  what your problem is.   What we need is a reproducible sequence of events leading up to the crash.

If you can reproduce the crash through the psql monitor, then we should work with that.   No sense in adding an extra layer of complexity by working through the ODBC driver.

The same goes for the junkfilter patch.   The errors as you describe, do not point to the junkfilter patch.   Admittedly, it is possible.   See if the problem can be reproduced without the junkfilter.


Mon, 07 Sep 1998 10:56:21 -0400
David Hartwig <daybee@bellatlantic.net>
Re: [INTERFACES] Re: DELETE FROM TABLE doesn't work (AGAIN)
Hi Jose, hi Hackers!

On Mon, 7 Sep 1998 17:09:04 +0200, Sferacarta Software wrote:

>GF> I've applied the junkfilter because I want to use the ODBC-driver to 
>GF> let Access make some querys on a postgres-db.
>
>GF> But since this patch i can't Delete tuples anymore. A 'Delete from 
>GF> table  where x=1;' will crash the backend. :-(
>
>GF> Any hints?
>
>GF> I tryed this with postgresql.6.3.2 with all patches and with no other
>GF> patches applied.

>Now I have this problem too.
>This is the second time for me. The other day (August 6)I sent an help message to the
>list, because my backend crashed during a DELETE or a DROP DATABASE
>statement. I had no response till Sept 2 and then I decide to re-install PostgreSQL.
>It works well until today (Sept 7).
>
>I'm working with ODBC and Access too.
>
>Please help. I don't want to re-install PostgreSQL again.

I reinstalled Postgresql with this patch about 10 times in the last 2 days, but without success. :-(

I tried now to use the snapshot, and it compiled nearly without problems (in /src/interfaces/ecpg/preproc/preproc.y is a ';' missing on line 1562), but the ODBC-Driver can't connect to the database. The logfile 
says:
----------------
conn=71501948, SQLDriverConnect( in)='DRIVER={PostgreSQL};', fDriverCompletion=1
conn=71501948, SQLDriverConnect(out)='DRIVER={PostgreSQL};DATABASE=test;SERVER=hp;PORT=5432;UID=gerald;PWD=av;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=
0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS='
Global Options: fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=255, max_longvarchar_size=4094
                disable_optimizer=1, unique_index=0, use_declarefetch=1
                text_as_longvarchar=1, unknowns_as_longvarchar=0, bools_as_char=1
                extra_systable_prefixes='dd_;', conn_settings=''
conn=71501948, query=' '
conn=71501948, query='BEGIN'
conn=71501948, query='set DateStyle to 'ISO'; set geqo to 'OFF''
Command response: 'SET VARIABLE'
conn=71501948, query='declare SQL_CUR71516440 cursor for select oid from pg_type where typname='lo''
conn=71501948, query='fetch 100 in SQL_CUR71516440'
    [ fetched 0 rows ]
conn=71501948, query='close SQL_CUR71516440'
conn=71501948, query='END'
conn=71501948, query='BEGIN'
conn=71501948, query='declare SQL_CUR71582124 cursor for select relname, usename, relhasrules from pg_class, pg_user where relkind = 'r'  and relname !~ '^xinv[0-9]+' and int4out(usesysid) = int4out
(relowner) order by relname'
conn=71501948, query='fetch 100 in SQL_CUR71582124'
    [ fetched 30 rows ]
conn=71501948, query='close SQL_CUR71582124'
conn=71501948, query='END'
conn=71501948, query='BEGIN'
conn=71501948, query='declare SQL_CUR71582124 cursor for select u.usename, c.relname, a.attname, a.atttypid,t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull from pg_user u, pg_class c, pg_attribute 
a, pg_type t where int4out(u.usesysid) = int4out(c.relowner) and c.oid= a.attrelid and a.atttypid = t.oid and (a.attnum > 0) and c.relname like 'test' order by attnum'
conn=71501948, query='fetch 100 in SQL_CUR71582124'
    [ fetched 2 rows ]
STATEMENT ERROR: func=SQLFetch, desc='', errnum=3, errmsg='Null statement result in SQLFetch.'
                 ------------------------------------------------------------
                 hdbc=0, stmt=71630847, result=0
                 manual_result=0, prepare=0, internal=0
                 bindings=0, bindings_allocated=0
                 parameters=0, parameters_allocated=0
                 statement_type=0, statement='(null)'
                 stmt_with_params=''
                 data_at_exec=0, current_exec_param=0, put_data=0
                 currTuple=0, current_col=0, lobj_fd=0
                 maxRows=0, rowset_size=0, keyset_size=0, cursor_type=0, scroll_concurrency=0
                 cursor_name=''
                 ----------------QResult Info -------------------------------
INVALID CONNECTION HANDLE ERROR: func=SQLFetch, desc=''
STATEMENT ERROR: func=SQLColumns, desc='', errnum=0, errmsg='Null statement result in SQLFetch.'
                 ------------------------------------------------------------
                 hdbc=71501948, stmt=71516440, result=72551288
                 manual_result=1, prepare=0, internal=0
                 bindings=72551372, bindings_allocated=14
                 parameters=0, parameters_allocated=0
                 statement_type=-2, statement='(null)'
                 stmt_with_params=''
                 data_at_exec=-1, current_exec_param=-1, put_data=0
                 currTuple=-1, current_col=-1, lobj_fd=-1
                 maxRows=0, rowset_size=1, keyset_size=0, cursor_type=0, scroll_concurrency=1
                 cursor_name=''
                 ----------------QResult Info -------------------------------
                 fields=72551348, manual_tuples=71647992, backend_tuples=0, tupleField=0, conn=0
                 fetch_count=0, fcount=0, num_fields=0, cursor='(null)'
                 message='(null)', command='(null)', notice='(null)'
                 status=0, inTuples=0
CONN ERROR: func=SQLColumns, desc='', errnum=0, errmsg=''
            ------------------------------------------------------------
            henv=72548484, conn=71501948, status=1, num_stmts=16
            sock=72548500, stmts=72548540, lobj_type=-999
            ---------------- Socket Info -------------------------------
            socket=66, reverse=0, errornumber=0, errormsg='(null)'
            buffer_in=71508240, buffer_out=71512340
            buffer_filled_in=279, buffer_filled_out=0, buffer_read_in=279
conn=71501948, SQLDisconnect
conn=71501948, query='ABORT'
---------
And with the snapshot of sept. 6th, it complains about a missing MSysConf-Table. :-(
--------
conn=71501948, query='declare SQL_CUR71516440 cursor for SELECT Config, nValue FROM MSysConf'
ERROR from backend during send_query: 'ERROR:  msysconf: Table does not exist.'
--------

Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).

Best regards,
Gerald Fischer



Mon, 07 Sep 1998 18:28:41 +0200
"Gerald Fischer" <pgsql@gefi.at>
Re: [INTERFACES] Re: DELETE FROM TABLE doesn't work (AGAIN)