From Darko.Prenosil@finteh.hr Wed Oct 3 17:14:43 2001 Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by postgresql.org (8.11.3/8.11.4) with ESMTP id f93HEgn52354 for ; Wed, 3 Oct 2001 13:14:43 -0400 (EDT) (envelope-from Darko.Prenosil@finteh.hr) Received: from darko (zg04-183.dialin.iskon.hr [213.191.137.184]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with SMTP id f93HECV17973; Wed, 3 Oct 2001 19:14:13 +0200 (MEST) Message-ID: <007e01c14c2e$d1e69240$ef00000a@darko> From: "Darko Prenosil" To: "Bruce Momjian" , "Tom Lane" Cc: "pgsql interfaces" Subject: Date: Wed, 3 Oct 2001 19:13:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C14C3F.6F511540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Archive-Number: 200110/8 X-Sequence-Number: 1976 This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C14C3F.6F511540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys,=20 Sorry for bothering you, but we ran into a situation... Story goes like this:=20 We wanted to use non-blocking PQSendQuery to send a large query which consi= sts of many SELECTs. Our pglib interface sent just first 8192 bytes and ret= urned 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 +=3D avail; s +=3D avail; nbytes -=3D avail; if (pqFlush(conn))=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 return EOF; avail =3D conn->outBufSize; } ........... } ************************************* pqFlush(PGconn *conn) { ............ #ifdef USE_SSL /* can't do anything for our SSL users yet */ if (conn->ssl =3D=3D NULL) { #endif if (pqIsnonblocking(conn)) { /* shift the contents of the buffer */ memmove(conn->outBuffer, ptr, len); conn->outCount =3D len; return EOF; <- Why it returns EOF a= fter 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 =3D=3D NULL) { if (pqIsnonblocking(conn)) { /* shift the contents of the buffer */ memmove(conn->outBuffer, ptr, len); conn->outCount =3D len; return EOF;=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 } } #endif we succeed to send queries bigger than 8k. We tried to figure what is happe= ning, 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 ------=_NextPart_000_0075_01C14C3F.6F511540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi guys,
Sorry for bothering you, but we ran into a= =20 situation...
Story goes like this:
We wanted to use non-blocking PQSendQuery = to send a=20 large query which consists of many SELECTs. Our pglib interface sent just= =20 first 8192 bytes and returned EOF. Whole query was more than=20 64k.
 
We took a brief look through the source an= d here is=20 what confuses us:
 
These two chunks of code are from=20 fe-misc.c
 
pqPutBytes(const char *s, size_t nbytes, P= Gconn=20 *conn){
........
while (nbytes >=20 avail)
 {
  memcpy(conn->outBuffer + conn->outCo= unt,=20 s, avail);
  conn->outCount +=3D avail;
  s += =3D=20 avail;
  nbytes -=3D avail;
  if=20 (pqFlush(conn))          =             &nb= sp;
   return EOF;
 &nb= sp;avail=20 =3D conn->outBufSize;
 }
...........
}
 
*************************************
pqFlush(PGconn *conn) {
............
#ifdef USE_SSL
   /* can= 't do=20 anything for our SSL users yet */
   if (conn->ssl =3D= =3D=20 NULL)
   {
#endif
    if=20 (pqIsnonblocking(conn))
    {
   &= nbsp; /*=20 shift the contents of the buffer=20 */
     memmove(conn->outBuffer, ptr,=20 len);
     conn->outCount =3D=20 len;
     return=20 EOF;            = ;            &n= bsp;           <-=20 Why it returns EOF after just shifting the buffer=20 ???
    }
#ifdef=20 USE_SSL
   }
#endif
...............
}
 
 
When we corected the code to look like=20 this:
 
#ifdef USE_SSL
   /* can= 't do=20 anything for our SSL users yet */
   if (conn->ssl =3D= =3D=20 NULL)
   {
    if=20 (pqIsnonblocking(conn))
    {
   &= nbsp; /*=20 shift the contents of the buffer=20 */
     memmove(conn->outBuffer, ptr,=20 len);
     conn->outCount =3D=20 len;
     return=20 EOF;            = ;            &n= bsp;          
    }
   }
#endif
<= /DIV>
 
we succeed to send queries bigger than 8k.= We tried=20 to figure what is happening, and saw that there
is few pqWait calls, but our queries are s= end=20 correctly. Is there some fact that we are missing ?
Can You please explain ???
May= be it is=20 important to say that we are compiling library for WIN32.
 
 
Thanks.
Darko
 
------=_NextPart_000_0075_01C14C3F.6F511540-- From tgl@sss.pgh.pa.us Wed Oct 3 17:45:12 2001 Received: from sss.pgh.pa.us ([192.204.191.242]) by postgresql.org (8.11.3/8.11.4) with ESMTP id f93HjCn61165 for ; Wed, 3 Oct 2001 13:45:12 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id f93HfYI06312; Wed, 3 Oct 2001 13:41:35 -0400 (EDT) To: "Darko Prenosil" cc: "Bruce Momjian" , "pgsql interfaces" Subject: Re: In-reply-to: <007e01c14c2e$d1e69240$ef00000a@darko> References: <007e01c14c2e$d1e69240$ef00000a@darko> Comments: In-reply-to "Darko Prenosil" message dated "Wed, 03 Oct 2001 19:13:07 +0200" Date: Wed, 03 Oct 2001 13:41:34 -0400 Message-ID: <6309.1002130894@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200110/9 X-Sequence-Number: 1977 "Darko Prenosil" 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