Re: Error on PQputline()

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
>

Responses

Browse pgsql-hackers by date

  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()