Обсуждение:
Hi guys,
Sorry for bothering you, but we ran into a situation...
Story goes like this:
We wanted to use non-blocking PQSendQuery to send a large query which consists of many SELECTs. Our pglib interface sent just first 8192 bytes and returned EOF. Whole query was more than 64k.
We took a brief look through the source and here is what confuses us:
These two chunks of code are from fe-misc.c
pqPutBytes(const char *s, size_t nbytes, PGconn *conn){
........
while (nbytes > avail)
{
memcpy(conn->outBuffer + conn->outCount, s, avail);
conn->outCount += avail;
s += avail;
nbytes -= avail;
if (pqFlush(conn))
{
memcpy(conn->outBuffer + conn->outCount, s, avail);
conn->outCount += avail;
s += avail;
nbytes -= avail;
if (pqFlush(conn))
return EOF;
avail = conn->outBufSize;
}
avail = conn->outBufSize;
}
...........
}
*************************************
pqFlush(PGconn *conn) {
............
#ifdef USE_SSL
/* can't do anything for our SSL users yet */
if (conn->ssl == NULL)
{
#endif
if (pqIsnonblocking(conn))
{
/* shift the contents of the buffer */
memmove(conn->outBuffer, ptr, len);
conn->outCount = len;
return EOF; <- Why it returns EOF after just shifting the buffer ???
}
#ifdef USE_SSL
}
#endif
/* can't do anything for our SSL users yet */
if (conn->ssl == NULL)
{
#endif
if (pqIsnonblocking(conn))
{
/* shift the contents of the buffer */
memmove(conn->outBuffer, ptr, len);
conn->outCount = len;
return EOF; <- Why it returns EOF after just shifting the buffer ???
}
#ifdef USE_SSL
}
#endif
...............
}
When we corected the code to look like this:
#ifdef USE_SSL
/* can't do anything for our SSL users yet */
if (conn->ssl == NULL)
{
if (pqIsnonblocking(conn))
{
/* shift the contents of the buffer */
memmove(conn->outBuffer, ptr, len);
conn->outCount = len;
return EOF;
/* can't do anything for our SSL users yet */
if (conn->ssl == NULL)
{
if (pqIsnonblocking(conn))
{
/* shift the contents of the buffer */
memmove(conn->outBuffer, ptr, len);
conn->outCount = len;
return EOF;
}
}
#endif
}
#endif
we succeed to send queries bigger than 8k. We tried to figure what is happening, and saw that there
is few pqWait calls, but our queries are send correctly. Is there some fact that we are missing ?
Can You please explain ???
Maybe it is important to say that we are compiling library for WIN32.Thanks.
Darko
"Darko Prenosil" <Darko.Prenosil@finteh.hr> writes: > We wanted to use non-blocking PQSendQuery to send a large query which = > consists of many SELECTs. Our pglib interface sent just first 8192 bytes = > and returned EOF. Whole query was more than 64k. I've said since day one that libpq's non-blocking mode is fundamentally broken --- see http://fts.postgresql.org/db/mw/msg.html?mid=35774 and rest of that thread. Tempt me not too far, or I'll rip it all out until someone reimplements it in a non-broken fashion ... regards, tom lane
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Darko Prenosil" <Darko.Prenosil@finteh.hr> Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; "pgsql interfaces" <pgsql-interfaces@postgresql.org> Sent: Wednesday, October 03, 2001 7:41 PM Subject: Re: [INTERFACES] > > I've said since day one that libpq's non-blocking mode is fundamentally > broken --- see http://fts.postgresql.org/db/mw/msg.html?mid=35774 and > rest of that thread. Tempt me not too far, or I'll rip it all out > until someone reimplements it in a non-broken fashion ... > Sorry, we did not know that "NON-BLOCKING" is in such bad shape, and only tried to help !!! Best regards !
> "Darko Prenosil" <Darko.Prenosil@finteh.hr> writes: > > We wanted to use non-blocking PQSendQuery to send a large query which = > > consists of many SELECTs. Our pglib interface sent just first 8192 bytes = > > and returned EOF. Whole query was more than 64k. > > I've said since day one that libpq's non-blocking mode is fundamentally > broken --- see http://fts.postgresql.org/db/mw/msg.html?mid=35774 and > rest of that thread. Tempt me not too far, or I'll rip it all out > until someone reimplements it in a non-broken fashion ... This is my fault. I voted for its inclusion even though Tom said it was not reliable. I thought someone would have fixed it by now but perhaps it is not fixable. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026