Issues with the latest 6.5 source
I refreshed my 6.5 source last night (last time was early April). This had
some patches to case and coalesce that I needed. This is working great
except for the following two areas:
1) The \g option in pgsql is failing. I have been using this technique
for months to create a script file from and SQL statement and then execute
the file. Here is the steps that worked before I pulled down code last
night:
\g sip_revoke_all.sql
unexpected character Z following 'I'
Once the above error occurs, the script will hang
until I manually break (ctrl-c).
2) My Access97 application using ODBC can't connect to the database.
Nothing has changed other than rebuilding the source. In attempts to fix
this, I and destroyed my databases, rm $PGDATA, and performed initdb. I have
verified that pg_hba.conf is correct before and after recreating my
databases. The Psqlodbc.log log file is below. I can log onto the
database using psql on my linux workstation just fine.
Has anything changed in the code recently (within the past 3 weeks) that
could have had some effect these two conditions? I am at a complete stand
still until I can get my ODBC issue resolved. I can work around item 1.
Thanks Michael
Psqlodbc.log file:
conn=159330904, SQLDriverConnect( in)='DSN=PostgreSQL;', fDriverCompletion=1
DSN info:
DSN='PostgreSQL',server='192.168.97.2',port='5432',dbase='mp',user='postgres
',passwd=''
readonly='0',protocol='6.4',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings=''
translation_dll='',translation_option=''
Global Options: Version='06.40.0004', fetch=100, socket=4096,
unknown_sizes=0, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, ksqo=1, unique_index=1,
use_declarefetch=1
text_as_longvarchar=1, unknowns_as_longvarchar=0,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings=''
conn=159330904, query=' '
CONN ERROR: func=SQLDriverConnect, desc='Error from CC_Connect', errnum=105,
errmsg='The database does not exist on the server
or user authentication failed.'
------------------------------------------------------------
henv=159330888, conn=159330904, status=0, num_stmts=16
sock=159337240, stmts=159345496, lobj_type=-999
---------------- Socket Info -------------------------------
socket=360, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=159337288, buffer_out=159341392
buffer_filled_in=2, buffer_filled_out=0, buffer_read_in=2
Michael J Davis <michael.j.davis@tvguide.com> writes:
1) The \g option in pgsql is failing.
I'll look at that this evening --- I was fooling with psql's command
parsing a couple days ago, might have busted it.
2) My Access97 application using ODBC can't connect to the database.
Dunno about this one.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue27Apr1999163108-050093C04F1F5173D211A27900105AA8FCFC145430@lambic.prevuenet.com | Resolved by subject fallback
Michael J Davis <michael.j.davis@tvguide.com> writes:
1) The \g option in pgsql is failing.
Fixed. I had managed to break the empty-query response protocol on
Sunday --- odd that none of the regression tests detected this. Sigh.
2) My Access97 application using ODBC can't connect to the database.
I now have a strong suspicion that this is caused by the same goof.
ODBC might issue an empty query during startup. (That used to be a
necessary part of the startup protocol; it isn't anymore, but ODBC
very possibly hasn't been changed.)
If you don't have CVS access and don't want to wait for tonight's
snapshot, here is the patch:
*** src/backend/tcop/dest.c~ Wed Apr 28 18:15:07 1999
--- src/backend/tcop/dest.c Wed Apr 28 18:15:45 1999
***************
*** 336,342 ****
* tell the fe that we saw an empty query string
* ----------------
*/
! pq_putbytes("I", 1);
break; case Local:
--- 336,342 ----
* tell the fe that we saw an empty query string
* ----------------
*/
! pq_putbytes("I", 2); /* note we send I and \0 */
break;case Local:
Let us know if that helps...
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue27Apr1999163108-050093C04F1F5173D211A27900105AA8FCFC145430@lambic.prevuenet.com | Resolved by subject fallback
Yea!!!!! This fixes the problem. I will test the \g option in a few hours
after I have completely repopulated my data. How about adding a comment
about the importance of this patch? Thanks Tom for tracking this down so
quickly.
Thanks, Michael
-----Original Message-----
From: Tom Lane [SMTP:tgl@sss.pgh.pa.us]
Sent: Wednesday, April 28, 1999 4:29 PM
To: Michael J Davis
Cc: pgsql-interfaces@postgreSQL.org;
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Issues with the latest 6.5 source
Michael J Davis <michael.j.davis@tvguide.com> writes:
1) The \g option in pgsql is failing.
Fixed. I had managed to break the empty-query response protocol on
Sunday --- odd that none of the regression tests detected this.
Sigh.
2) My Access97 application using ODBC can't connect to the
database.
I now have a strong suspicion that this is caused by the same goof.
ODBC might issue an empty query during startup. (That used to be a
necessary part of the startup protocol; it isn't anymore, but ODBC
very possibly hasn't been changed.)
If you don't have CVS access and don't want to wait for tonight's
snapshot, here is the patch:
*** src/backend/tcop/dest.c~ Wed Apr 28 18:15:07 1999
--- src/backend/tcop/dest.c Wed Apr 28 18:15:45 1999
***************
*** 336,342 ****
* tell the fe that we saw an
empty query string
* ----------------
*/
! pq_putbytes("I", 1);
break; case Local:
--- 336,342 ----
* tell the fe that we saw an
empty query string
* ----------------
*/
! pq_putbytes("I", 2); /* note we send I and
\0 */
break;case Local:
Let us know if that helps...
regards, tom lane
Import Notes
Resolved by subject fallback