From: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Error on PQputline() |
Date: | 2002-05-17 23:41:34 |
Message-ID: | D90A5A6C612A39408103E6ECDD77B82920CE78@voyager.corporate.connx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Friday, May 17, 2002 4:38 PM
> To: Dann Corbit
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Error on PQputline()
>
>
> "Dann Corbit" <DCorbit(at)connx(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-17 23:46:34 | Re: Error on PQputline() |
Previous Message | Tom Lane | 2002-05-17 23:37:49 | Re: Error on PQputline() |