Re: Protocol de-synchronisation bug, bogus query sent - Mailing list pgsql-odbc
From | Inoue, Hiroshi |
---|---|
Subject | Re: Protocol de-synchronisation bug, bogus query sent |
Date | |
Msg-id | 53A26635.4030200@tpf.co.jp Whole thread Raw |
In response to | Protocol de-synchronisation bug, bogus query sent (Craig Ringer <craig@2ndquadrant.com>) |
Responses |
Re: Protocol de-synchronisation bug, bogus query sent
Re: Protocol de-synchronisation bug, bogus query sent |
List | pgsql-odbc |
Hi Craig, The code seems for v0/v1 protocol. Though I don't remember well, the dance was probably because v0/v1 didn't have clear sync mechanism. I wonder why the code reached there. The flag beforeV2 is broken? regards, Hiroshi Inoue (2014/06/19 12:44), Craig Ringer wrote: > Hi folks > > I've found a bug in psqlODBC, in CC_send_query_append, where psqlODBC > gets out of sync with the server's idea of the connection state and both > wait for each other indefinitely. > > So far I've only reproduced it as part of debugging a larger issue. I've > only actually seen it when psqlODBC establishes an "isolated" XA > connection after failing to acquire a lock on the DTC connection in > IAsyncPG::getLockedXAConn(). If the client has specified a connect-time > query string with a DSN like: > > DRIVER={PostgreSQL ANSI};SERVER=LOCALHOST;DATABASE=postgres;A6=set > search_path to someschema;UID=;PWD=;BI=-5;debug=1;commlog=1; > > ... but it's clearly a bug in its own right, so I'll write it up here > and propose a fix. > > > Patch attached, or you can pull the branch: > > fix-febe-protocol-desync-emptyquery > > from https://github.com/ringerc/psqlODBC.git > > > > The whole code block around connection.c:3082 appears to be attempting > to send an empty query in order to elicit an 'I' (EmptyQueryResponse) > message. It sends a malformed protocol message: > > SOCK_put_string(self->sock, "Q "); > SOCK_flush_output(self->sock); > > so the server just waits for the rest of the message, never responding. > > When the connection is killed by program exit later, the server will log: > > LOG: unexpected EOF within message length word > LOG: disconnection: session time: 0:00:08.910 user=Administrator > database=XXXX host=127.0.0.1 port=53705 > LOG: could not receive data from client: No connection could be made > because the target machine actively refused it. > > > That's because the V3 protocol specifies that the message format for > Query is: > > 'Q' > [32 bit integer] > [query string] > > http://www.postgresql.org/docs/current/static/protocol-message-formats.html > > ... but psqlODBC just sends: > > 'Q' > '\x20' > '\x00' > > If it is really necessary to go through this empty-query dance, then for > the V3 protocol the correct message would be: > > /* Send an empty query to elicit an 'I' (EmptyQueryResponse) > * from the server */ > SOCK_put_char(self->sock, 'Q'); > SOCK_put_int(self->sock, 5, 4); > SOCK_put_char(self->sock, '\0'); > > > > Since no 'I' message is ever received the next message is 'Z' > (ReadyForQuery). psqlODBC consumes this and carries on waiting for the > next message, as it has set emptyreqs=1 to expect 'I' messages. So it > waits forever, since the server thinks it's waiting for psqlODBC to > finish sending the prior protocol message. > > It isn't clear to me why psqlODBC does this weird dance with empty > queries at all, but it's certainly doing it wrong. > > The attached patch fixes the immediate problem, but I'd like to see if > this can be simplified out entirely in favour of, in ascending > size-of-work order, (a) using a protocol sync message, then (b) deleting > as much as possible of this custom protocol handling code entirely and > using libpq. -- I am using the free version of SPAMfighter. SPAMfighter has removed 10973 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
pgsql-odbc by date: