Out of memory while reading tuples error - Mailing list pgsql-odbc

Hi:
     When executing a SQL statement with a large # of records (500,000 in this case),
I am getting " Out of memory while reading tuples error"
                           Communication error while getting a tuple;
                           Error fetching next row

I turned on USEDECLAREFETCH=1  (B6=1), which has no effect on this error.

Any Ideas?

Barry Bell
Senior Developer/Analyst
Logistics
Harte Hanks
1525 NW 3rd ST
Deerfield Beach FL, 33442
954-429-3771 Ext 267 office
954-281-1464 fax

hartehanks.com / linkedin / twitter / facebook

-----Original Message-----
From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Inoue, Hiroshi
Sent: Thursday, June 19, 2014 12:25 AM
To: Craig Ringer
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Protocol de-synchronisation bug, bogus query sent

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
syncmechanism. 
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



--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc