Out of memory while reading tuples error

From: Barry Bell <Barry(dot)Bell(at)hartehanks(dot)com>
To: "Inoue, Hiroshi" <inoue(at)tpf(dot)co(dot)jp>
Cc: "pgsql-odbc(at)postgresql(dot)org" <pgsql-odbc(at)postgresql(dot)org>
Subject: Out of memory while reading tuples error
Date: 2014-06-19 15:14:08
Message-ID: 7de4876cf1284c7280461aaf5fb5bd41@BY2PR08MB281.namprd08.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)postgresql(dot)org [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Inoue, Hiroshi
Sent: Thursday, June 19, 2014 12:25 AM
To: Craig Ringer
Cc: pgsql-odbc(at)postgresql(dot)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 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

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

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Jade Koskela 2014-06-19 22:26:02 Re: Problem in SQLFreeHandle (Statement)
Previous Message Stephen Frost 2014-06-19 13:03:37 Re: Removing support for v1 and v2 protocols?