Re: Error on PQputline() - Mailing list pgsql-hackers
| From | Dann Corbit |
|---|---|
| Subject | Re: Error on PQputline() |
| Date | |
| Msg-id | D90A5A6C612A39408103E6ECDD77B82920CE78@voyager.corporate.connx.com Whole thread Raw |
| In response to | Error on PQputline() ("Dann Corbit" <DCorbit@connx.com>) |
| Responses |
Re: Error on PQputline()
|
| List | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, May 17, 2002 4:38 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Error on PQputline()
>
>
> "Dann Corbit" <DCorbit@connx.com> writes:
> >> You're running libpq with the nonblocking mode selected?
>
> > Actually no. It should be the default mode for a connection made by
> > PQconnectdb(). That's what made the error so puzzling.
>
> I'm confused too. For starters, I cannot find that error message
> string about 'A non-blocking socket operation could not be completed
> immediately' anywhere. Got any idea what's producing that? Exactly
> which version of libpq are you using, anyway?
7.1.3. Sorry for running on fossil PostgreSQL.
/* ---------------------------------------------------------------------
*/
/* pqFlush: send any data waiting in the output buffer*/
int
pqFlush(PGconn *conn)
{char *ptr = conn->outBuffer;int len = conn->outCount;
if (conn->sock < 0){ printfPQExpBuffer(&conn->errorMessage, "pqFlush() --
connection not open\n"); return EOF;}
/* * don't try to send zero data, allows us to use this function
without * too much worry about overhead */if (len == 0) return (0);
/* while there's still data to send */while (len > 0){ /* Prevent being SIGPIPEd if backend has closed the
connection. */
#ifndef WIN32 pqsigfunc oldsighandler = pqsignal(SIGPIPE,
SIG_IGN);
#endif
int sent;
#ifdef USE_SSL if (conn->ssl) sent = SSL_write(conn->ssl, ptr, len); else
#endif sent = send(conn->sock, ptr, len, 0);
#ifndef WIN32 pqsignal(SIGPIPE, oldsighandler);
#endif
if (sent < 0) {
/* * Anything except EAGAIN or EWOULDBLOCK is
trouble. If it's * EPIPE or ECONNRESET, assume we've lost the
backend * connection permanently. */ switch (errno) {
#ifdef EAGAIN case EAGAIN: break;
#endif
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK !=
EAGAIN)) case EWOULDBLOCK: break;
#endif case EINTR: continue;
case EPIPE:
#ifdef ECONNRESET case ECONNRESET:
#endif
printfPQExpBuffer(&conn->errorMessage,
"pqFlush() -- backend closed the channel unexpectedly.\n"
"\tThis probably means the backend terminated abnormally" " before or while
processing the request.\n");
/* * We used to close the socket
here, but that's a bad * idea since there might be
unread data waiting * (typically, a NOTICE message
from the backend * telling us it's committing
hara-kiri...). Leave * the socket open until
pqReadData finds no more data * can be read. */ return EOF;
/*
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvv
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!
*/ default:
printfPQExpBuffer(&conn->errorMessage, "pqFlush() -- couldn't send
data: errno=%d\n%s\n",
errno, strerror(errno)); /* We don't assume it's a fatal
error... */ return EOF;
/*
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!
*/ } } else { ptr += sent; len -= sent; }
if (len > 0) { /* We didn't send it all, wait till we can send
more */
/* * if the socket is in non-blocking mode we may
need to abort * here */
#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; }
#ifdef USE_SSL }
#endif
if (pqWait(FALSE, TRUE, conn)) return EOF; }}
conn->outCount = 0;
if (conn->Pfdebug) fflush(conn->Pfdebug);
return 0;
}
> > "Would it be faster to write a file to disk and read it again on the
> > local host for the server or to send the calls via libpq client
> > messages?"
>
> Good question. I'd recommend the messaging approach since it
> eliminates
> lots of headaches about file access privileges and so forth. But on
> some platforms the overhead could be high.
>
> regards, tom lane
>
pgsql-hackers by date: