1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* FILE
|
|
|
|
* fe-misc.c
|
|
|
|
*
|
|
|
|
* DESCRIPTION
|
|
|
|
* miscellaneous useful functions
|
1998-05-07 01:51:16 +02:00
|
|
|
*
|
|
|
|
* The communication routines here are analogous to the ones in
|
2019-08-05 05:14:58 +02:00
|
|
|
* backend/libpq/pqcomm.c and backend/libpq/pqformat.c, but operate
|
1998-05-07 01:51:16 +02:00
|
|
|
* in the considerably different environment of the frontend libpq.
|
|
|
|
* In particular, we work with a bare nonblock-mode socket, rather than
|
|
|
|
* a stdio stream, so that we can avoid unwanted blocking of the application.
|
|
|
|
*
|
|
|
|
* XXX: MOVE DEBUG PRINTOUT TO HIGHER LEVEL. As is, block and restart
|
|
|
|
* will cause repeat printouts.
|
|
|
|
*
|
|
|
|
* We must speak the same transmitted data representations as the backend
|
2003-04-19 02:02:30 +02:00
|
|
|
* routines.
|
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/interfaces/libpq/fe-misc.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#include "postgres_fe.h"
|
1998-08-17 05:50:43 +02:00
|
|
|
|
2001-07-20 19:45:06 +02:00
|
|
|
#include <signal.h>
|
|
|
|
#include <time.h>
|
2003-06-12 10:15:29 +02:00
|
|
|
|
1998-07-03 06:24:16 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
#include "win32.h"
|
1999-07-19 08:25:40 +02:00
|
|
|
#else
|
|
|
|
#include <unistd.h>
|
2022-08-13 13:33:34 +02:00
|
|
|
#include <sys/select.h>
|
2000-01-18 20:05:31 +01:00
|
|
|
#include <sys/time.h>
|
1998-05-07 01:51:16 +02:00
|
|
|
#endif
|
1998-08-17 05:50:43 +02:00
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
#ifdef HAVE_POLL_H
|
|
|
|
#include <poll.h>
|
|
|
|
#endif
|
1996-11-03 08:14:32 +01:00
|
|
|
|
2000-01-20 05:11:52 +01:00
|
|
|
#include "libpq-fe.h"
|
|
|
|
#include "libpq-int.h"
|
2000-01-29 17:58:54 +01:00
|
|
|
#include "mb/pg_wchar.h"
|
2006-05-23 21:28:45 +02:00
|
|
|
#include "pg_config_paths.h"
|
2019-10-23 06:08:53 +02:00
|
|
|
#include "port/pg_bswap.h"
|
1998-08-09 04:59:33 +02:00
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
static int pqPutMsgBytes(const void *buf, size_t len, PGconn *conn);
|
|
|
|
static int pqSendSome(PGconn *conn, int len);
|
2006-05-18 20:19:47 +02:00
|
|
|
static int pqSocketCheck(PGconn *conn, int forRead, int forWrite,
|
2003-03-06 04:16:55 +01:00
|
|
|
time_t end_time);
|
|
|
|
static int pqSocketPoll(int sock, int forRead, int forWrite, time_t end_time);
|
2001-07-06 19:58:53 +02:00
|
|
|
|
2010-12-22 14:23:56 +01:00
|
|
|
/*
|
|
|
|
* PQlibVersion: return the libpq version number
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
PQlibVersion(void)
|
|
|
|
{
|
|
|
|
return PG_VERSION_NUM;
|
|
|
|
}
|
1998-08-09 04:59:33 +02:00
|
|
|
|
2010-05-08 18:39:53 +02:00
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2003-04-19 02:02:30 +02:00
|
|
|
* pqGetc: get 1 character from the connection
|
2001-08-17 17:11:15 +02:00
|
|
|
*
|
|
|
|
* All these routines return 0 on success, EOF on error.
|
|
|
|
* Note that for the Get routines, EOF only means there is not enough
|
|
|
|
* data in the buffer, not that there is necessarily a hard error.
|
|
|
|
*/
|
1997-03-16 19:51:29 +01:00
|
|
|
int
|
1998-05-07 01:51:16 +02:00
|
|
|
pqGetc(char *result, PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn->inCursor >= conn->inEnd)
|
|
|
|
return EOF;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
*result = conn->inBuffer[conn->inCursor++];
|
1997-03-16 19:51:29 +01:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
return 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
|
2001-07-06 19:58:53 +02:00
|
|
|
/*
|
2003-04-19 02:02:30 +02:00
|
|
|
* pqPutc: write 1 char to the current message
|
2001-07-06 19:58:53 +02:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
pqPutc(char c, PGconn *conn)
|
|
|
|
{
|
2003-04-19 02:02:30 +02:00
|
|
|
if (pqPutMsgBytes(&c, 1, conn))
|
2001-07-06 19:58:53 +02:00
|
|
|
return EOF;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2008-10-27 10:42:31 +01:00
|
|
|
* pqGets[_append]:
|
2001-08-17 17:11:15 +02:00
|
|
|
* get a null-terminated string from the connection,
|
|
|
|
* and store it in an expansible PQExpBuffer.
|
|
|
|
* If we run out of memory, all of the string is still read,
|
|
|
|
* but the excess characters are silently discarded.
|
|
|
|
*/
|
2008-10-27 10:42:31 +01:00
|
|
|
static int
|
|
|
|
pqGets_internal(PQExpBuffer buf, PGconn *conn, bool resetbuffer)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
|
|
|
/* Copy conn data to locals for faster search loop */
|
|
|
|
char *inBuffer = conn->inBuffer;
|
|
|
|
int inCursor = conn->inCursor;
|
|
|
|
int inEnd = conn->inEnd;
|
|
|
|
int slen;
|
|
|
|
|
|
|
|
while (inCursor < inEnd && inBuffer[inCursor])
|
|
|
|
inCursor++;
|
|
|
|
|
|
|
|
if (inCursor >= inEnd)
|
|
|
|
return EOF;
|
|
|
|
|
|
|
|
slen = inCursor - conn->inCursor;
|
1999-08-31 03:37:37 +02:00
|
|
|
|
2008-10-27 10:42:31 +01:00
|
|
|
if (resetbuffer)
|
|
|
|
resetPQExpBuffer(buf);
|
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
appendBinaryPQExpBuffer(buf, inBuffer + conn->inCursor, slen);
|
1998-05-07 01:51:16 +02:00
|
|
|
|
|
|
|
conn->inCursor = ++inCursor;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-10-27 10:42:31 +01:00
|
|
|
int
|
|
|
|
pqGets(PQExpBuffer buf, PGconn *conn)
|
|
|
|
{
|
|
|
|
return pqGets_internal(buf, conn, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
pqGets_append(PQExpBuffer buf, PGconn *conn)
|
|
|
|
{
|
|
|
|
return pqGets_internal(buf, conn, false);
|
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/*
|
|
|
|
* pqPuts: write a null-terminated string to the current message
|
|
|
|
*/
|
1998-05-07 01:51:16 +02:00
|
|
|
int
|
|
|
|
pqPuts(const char *s, PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2003-04-19 02:02:30 +02:00
|
|
|
if (pqPutMsgBytes(s, strlen(s) + 1, conn))
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
|
|
|
|
|
|
|
return 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
|
|
|
* pqGetnchar:
|
|
|
|
* get a string of exactly len bytes in buffer s, no null termination
|
|
|
|
*/
|
1997-03-16 19:51:29 +01:00
|
|
|
int
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
pqGetnchar(char *s, size_t len, PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2009-05-21 14:54:27 +02:00
|
|
|
if (len > (size_t) (conn->inEnd - conn->inCursor))
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
|
|
|
|
|
|
|
memcpy(s, conn->inBuffer + conn->inCursor, len);
|
1998-08-29 04:09:27 +02:00
|
|
|
/* no terminating null */
|
1998-09-01 06:40:42 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->inCursor += len;
|
1997-03-16 19:51:29 +01:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
return 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2012-04-05 00:27:56 +02:00
|
|
|
/*
|
|
|
|
* pqSkipnchar:
|
|
|
|
* skip over len bytes in input buffer.
|
|
|
|
*
|
|
|
|
* Note: this is primarily useful for its debug output, which should
|
|
|
|
* be exactly the same as for pqGetnchar. We assume the data in question
|
|
|
|
* will actually be used, but just isn't getting copied anywhere as yet.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pqSkipnchar(size_t len, PGconn *conn)
|
|
|
|
{
|
|
|
|
if (len > (size_t) (conn->inEnd - conn->inCursor))
|
|
|
|
return EOF;
|
|
|
|
|
|
|
|
conn->inCursor += len;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
|
|
|
* pqPutnchar:
|
2003-04-19 02:02:30 +02:00
|
|
|
* write exactly len bytes to the current message
|
2001-08-17 17:11:15 +02:00
|
|
|
*/
|
1997-03-16 19:51:29 +01:00
|
|
|
int
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
pqPutnchar(const char *s, size_t len, PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2003-04-19 02:02:30 +02:00
|
|
|
if (pqPutMsgBytes(s, len, conn))
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
1997-03-16 19:51:29 +01:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
return 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2003-06-21 23:51:35 +02:00
|
|
|
* pqGetInt
|
2001-08-17 17:11:15 +02:00
|
|
|
* read a 2 or 4 byte integer and convert from network byte order
|
|
|
|
* to local byte order
|
|
|
|
*/
|
1997-03-16 19:51:29 +01:00
|
|
|
int
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
pqGetInt(int *result, size_t bytes, PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-05-07 01:51:16 +02:00
|
|
|
uint16 tmp2;
|
|
|
|
uint32 tmp4;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-03-16 19:51:29 +01:00
|
|
|
switch (bytes)
|
|
|
|
{
|
|
|
|
case 2:
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn->inCursor + 2 > conn->inEnd)
|
|
|
|
return EOF;
|
|
|
|
memcpy(&tmp2, conn->inBuffer + conn->inCursor, 2);
|
|
|
|
conn->inCursor += 2;
|
2017-10-02 00:36:14 +02:00
|
|
|
*result = (int) pg_ntoh16(tmp2);
|
1997-03-16 19:51:29 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn->inCursor + 4 > conn->inEnd)
|
|
|
|
return EOF;
|
|
|
|
memcpy(&tmp4, conn->inBuffer + conn->inCursor, 4);
|
|
|
|
conn->inCursor += 4;
|
2017-10-02 00:36:14 +02:00
|
|
|
*result = (int) pg_ntoh32(tmp4);
|
1997-03-16 19:51:29 +01:00
|
|
|
break;
|
|
|
|
default:
|
2003-06-23 21:20:25 +02:00
|
|
|
pqInternalNotice(&conn->noticeHooks,
|
|
|
|
"integer of size %lu not supported by pqGetInt",
|
|
|
|
(unsigned long) bytes);
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
1997-03-16 19:51:29 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
return 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2003-06-21 23:51:35 +02:00
|
|
|
* pqPutInt
|
2003-04-19 02:02:30 +02:00
|
|
|
* write an integer of 2 or 4 bytes, converting from host byte order
|
2001-08-17 17:11:15 +02:00
|
|
|
* to network byte order.
|
|
|
|
*/
|
1997-03-16 19:51:29 +01:00
|
|
|
int
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
pqPutInt(int value, size_t bytes, PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-05-07 01:51:16 +02:00
|
|
|
uint16 tmp2;
|
|
|
|
uint32 tmp4;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-03-16 19:51:29 +01:00
|
|
|
switch (bytes)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-03-16 19:51:29 +01:00
|
|
|
case 2:
|
2017-10-02 00:36:14 +02:00
|
|
|
tmp2 = pg_hton16((uint16) value);
|
2003-04-19 02:02:30 +02:00
|
|
|
if (pqPutMsgBytes((const char *) &tmp2, 2, conn))
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
1997-03-16 19:51:29 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
2017-10-02 00:36:14 +02:00
|
|
|
tmp4 = pg_hton32((uint32) value);
|
2003-04-19 02:02:30 +02:00
|
|
|
if (pqPutMsgBytes((const char *) &tmp4, 4, conn))
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
1997-03-16 19:51:29 +01:00
|
|
|
break;
|
|
|
|
default:
|
2003-06-23 21:20:25 +02:00
|
|
|
pqInternalNotice(&conn->noticeHooks,
|
|
|
|
"integer of size %lu not supported by pqPutInt",
|
|
|
|
(unsigned long) bytes);
|
1998-05-07 01:51:16 +02:00
|
|
|
return EOF;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
return 0;
|
1997-03-16 19:51:29 +01:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2003-04-19 02:02:30 +02:00
|
|
|
* Make sure conn's output buffer can hold bytes_needed bytes (caller must
|
2003-04-22 02:08:07 +02:00
|
|
|
* include already-stored data into the value!)
|
2003-04-19 02:02:30 +02:00
|
|
|
*
|
2003-04-22 02:08:07 +02:00
|
|
|
* Returns 0 on success, EOF if failed to enlarge buffer
|
2003-04-19 02:02:30 +02:00
|
|
|
*/
|
2003-06-21 23:51:35 +02:00
|
|
|
int
|
2008-05-30 00:02:44 +02:00
|
|
|
pqCheckOutBufferSpace(size_t bytes_needed, PGconn *conn)
|
2003-04-19 02:02:30 +02:00
|
|
|
{
|
|
|
|
int newsize = conn->outBufSize;
|
|
|
|
char *newbuf;
|
|
|
|
|
2014-05-08 03:38:36 +02:00
|
|
|
/* Quick exit if we have enough space */
|
2008-05-30 00:02:44 +02:00
|
|
|
if (bytes_needed <= (size_t) newsize)
|
2003-04-19 02:02:30 +02:00
|
|
|
return 0;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/*
|
|
|
|
* If we need to enlarge the buffer, we first try to double it in size; if
|
|
|
|
* that doesn't work, enlarge in multiples of 8K. This avoids thrashing
|
|
|
|
* the malloc pool by repeated small enlargements.
|
|
|
|
*
|
|
|
|
* Note: tests for newsize > 0 are to catch integer overflow.
|
|
|
|
*/
|
|
|
|
do
|
|
|
|
{
|
|
|
|
newsize *= 2;
|
2008-05-30 00:02:44 +02:00
|
|
|
} while (newsize > 0 && bytes_needed > (size_t) newsize);
|
2003-04-19 02:02:30 +02:00
|
|
|
|
2008-05-30 00:02:44 +02:00
|
|
|
if (newsize > 0 && bytes_needed <= (size_t) newsize)
|
2003-04-19 02:02:30 +02:00
|
|
|
{
|
|
|
|
newbuf = realloc(conn->outBuffer, newsize);
|
|
|
|
if (newbuf)
|
|
|
|
{
|
|
|
|
/* realloc succeeded */
|
|
|
|
conn->outBuffer = newbuf;
|
|
|
|
conn->outBufSize = newsize;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
newsize = conn->outBufSize;
|
|
|
|
do
|
|
|
|
{
|
|
|
|
newsize += 8192;
|
2008-05-30 00:02:44 +02:00
|
|
|
} while (newsize > 0 && bytes_needed > (size_t) newsize);
|
2003-04-19 02:02:30 +02:00
|
|
|
|
2008-05-30 00:02:44 +02:00
|
|
|
if (newsize > 0 && bytes_needed <= (size_t) newsize)
|
2003-04-19 02:02:30 +02:00
|
|
|
{
|
|
|
|
newbuf = realloc(conn->outBuffer, newsize);
|
|
|
|
if (newbuf)
|
|
|
|
{
|
|
|
|
/* realloc succeeded */
|
|
|
|
conn->outBuffer = newbuf;
|
|
|
|
conn->outBufSize = newsize;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* realloc failed. Probably out of memory */
|
In libpq, always append new error messages to conn->errorMessage.
Previously, we had an undisciplined mish-mash of printfPQExpBuffer and
appendPQExpBuffer calls to report errors within libpq. This commit
establishes a uniform rule that appendPQExpBuffer[Str] should be used.
conn->errorMessage is reset only at the start of an application request,
and then accumulates messages till we're done. We can remove no less
than three different ad-hoc mechanisms that were used to get the effect
of concatenation of error messages within a sequence of operations.
Although this makes things quite a bit cleaner conceptually, the main
reason to do it is to make the world safer for the multiple-target-host
feature that was added awhile back. Previously, there were many cases
in which an error occurring during an individual host connection attempt
would wipe out the record of what had happened during previous attempts.
(The reporting is still inadequate, in that it can be hard to tell which
host got the failure, but that seems like a matter for a separate commit.)
Currently, lo_import and lo_export contain exceptions to the "never
use printfPQExpBuffer" rule. If we changed them, we'd risk reporting
an incidental lo_close failure before the actual read or write
failure, which would be confusing, not least because lo_close happened
after the main failure. We could improve this by inventing an
internal version of lo_close that doesn't reset the errorMessage; but
we'd also need a version of PQfn() that does that, and it didn't quite
seem worth the trouble for now.
Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
"cannot allocate memory for output buffer\n");
|
2003-04-19 02:02:30 +02:00
|
|
|
return EOF;
|
|
|
|
}
|
|
|
|
|
2003-04-22 02:08:07 +02:00
|
|
|
/*
|
|
|
|
* Make sure conn's input buffer can hold bytes_needed bytes (caller must
|
|
|
|
* include already-stored data into the value!)
|
|
|
|
*
|
|
|
|
* Returns 0 on success, EOF if failed to enlarge buffer
|
|
|
|
*/
|
|
|
|
int
|
2008-05-30 00:02:44 +02:00
|
|
|
pqCheckInBufferSpace(size_t bytes_needed, PGconn *conn)
|
2003-04-22 02:08:07 +02:00
|
|
|
{
|
|
|
|
int newsize = conn->inBufSize;
|
|
|
|
char *newbuf;
|
|
|
|
|
2014-05-08 03:38:36 +02:00
|
|
|
/* Quick exit if we have enough space */
|
|
|
|
if (bytes_needed <= (size_t) newsize)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Before concluding that we need to enlarge the buffer, left-justify
|
|
|
|
* whatever is in it and recheck. The caller's value of bytes_needed
|
|
|
|
* includes any data to the left of inStart, but we can delete that in
|
|
|
|
* preference to enlarging the buffer. It's slightly ugly to have this
|
|
|
|
* function do this, but it's better than making callers worry about it.
|
|
|
|
*/
|
|
|
|
bytes_needed -= conn->inStart;
|
|
|
|
|
|
|
|
if (conn->inStart < conn->inEnd)
|
|
|
|
{
|
|
|
|
if (conn->inStart > 0)
|
|
|
|
{
|
|
|
|
memmove(conn->inBuffer, conn->inBuffer + conn->inStart,
|
|
|
|
conn->inEnd - conn->inStart);
|
|
|
|
conn->inEnd -= conn->inStart;
|
|
|
|
conn->inCursor -= conn->inStart;
|
|
|
|
conn->inStart = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* buffer is logically empty, reset it */
|
|
|
|
conn->inStart = conn->inCursor = conn->inEnd = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Recheck whether we have enough space */
|
2008-05-30 00:02:44 +02:00
|
|
|
if (bytes_needed <= (size_t) newsize)
|
2003-04-22 02:08:07 +02:00
|
|
|
return 0;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-04-22 02:08:07 +02:00
|
|
|
/*
|
|
|
|
* If we need to enlarge the buffer, we first try to double it in size; if
|
|
|
|
* that doesn't work, enlarge in multiples of 8K. This avoids thrashing
|
|
|
|
* the malloc pool by repeated small enlargements.
|
|
|
|
*
|
|
|
|
* Note: tests for newsize > 0 are to catch integer overflow.
|
|
|
|
*/
|
|
|
|
do
|
|
|
|
{
|
|
|
|
newsize *= 2;
|
2008-05-30 00:02:44 +02:00
|
|
|
} while (newsize > 0 && bytes_needed > (size_t) newsize);
|
2003-04-22 02:08:07 +02:00
|
|
|
|
2008-05-30 00:02:44 +02:00
|
|
|
if (newsize > 0 && bytes_needed <= (size_t) newsize)
|
2003-04-22 02:08:07 +02:00
|
|
|
{
|
|
|
|
newbuf = realloc(conn->inBuffer, newsize);
|
|
|
|
if (newbuf)
|
|
|
|
{
|
|
|
|
/* realloc succeeded */
|
|
|
|
conn->inBuffer = newbuf;
|
|
|
|
conn->inBufSize = newsize;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
newsize = conn->inBufSize;
|
|
|
|
do
|
|
|
|
{
|
|
|
|
newsize += 8192;
|
2008-05-30 00:02:44 +02:00
|
|
|
} while (newsize > 0 && bytes_needed > (size_t) newsize);
|
2003-04-22 02:08:07 +02:00
|
|
|
|
2008-05-30 00:02:44 +02:00
|
|
|
if (newsize > 0 && bytes_needed <= (size_t) newsize)
|
2003-04-22 02:08:07 +02:00
|
|
|
{
|
|
|
|
newbuf = realloc(conn->inBuffer, newsize);
|
|
|
|
if (newbuf)
|
|
|
|
{
|
|
|
|
/* realloc succeeded */
|
|
|
|
conn->inBuffer = newbuf;
|
|
|
|
conn->inBufSize = newsize;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* realloc failed. Probably out of memory */
|
In libpq, always append new error messages to conn->errorMessage.
Previously, we had an undisciplined mish-mash of printfPQExpBuffer and
appendPQExpBuffer calls to report errors within libpq. This commit
establishes a uniform rule that appendPQExpBuffer[Str] should be used.
conn->errorMessage is reset only at the start of an application request,
and then accumulates messages till we're done. We can remove no less
than three different ad-hoc mechanisms that were used to get the effect
of concatenation of error messages within a sequence of operations.
Although this makes things quite a bit cleaner conceptually, the main
reason to do it is to make the world safer for the multiple-target-host
feature that was added awhile back. Previously, there were many cases
in which an error occurring during an individual host connection attempt
would wipe out the record of what had happened during previous attempts.
(The reporting is still inadequate, in that it can be hard to tell which
host got the failure, but that seems like a matter for a separate commit.)
Currently, lo_import and lo_export contain exceptions to the "never
use printfPQExpBuffer" rule. If we changed them, we'd risk reporting
an incidental lo_close failure before the actual read or write
failure, which would be confusing, not least because lo_close happened
after the main failure. We could improve this by inventing an
internal version of lo_close that doesn't reset the errorMessage; but
we'd also need a version of PQfn() that does that, and it didn't quite
seem worth the trouble for now.
Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
"cannot allocate memory for input buffer\n");
|
2003-04-22 02:08:07 +02:00
|
|
|
return EOF;
|
|
|
|
}
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/*
|
|
|
|
* pqPutMsgStart: begin construction of a message to the server
|
|
|
|
*
|
|
|
|
* msg_type is the message type byte, or 0 for a message without type byte
|
|
|
|
* (only startup messages have no type byte)
|
|
|
|
*
|
|
|
|
* Returns 0 on success, EOF on error
|
|
|
|
*
|
|
|
|
* The idea here is that we construct the message in conn->outBuffer,
|
|
|
|
* beginning just past any data already in outBuffer (ie, at
|
|
|
|
* outBuffer+outCount). We enlarge the buffer as needed to hold the message.
|
2003-06-08 19:43:00 +02:00
|
|
|
* When the message is complete, we fill in the length word (if needed) and
|
|
|
|
* then advance outCount past the message, making it eligible to send.
|
|
|
|
*
|
|
|
|
* The state variable conn->outMsgStart points to the incomplete message's
|
|
|
|
* length word: it is either outCount or outCount+1 depending on whether
|
2021-03-04 09:45:55 +01:00
|
|
|
* there is a type byte. The state variable conn->outMsgEnd is the end of
|
|
|
|
* the data collected so far.
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
int
|
2021-03-04 09:45:55 +01:00
|
|
|
pqPutMsgStart(char msg_type, PGconn *conn)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2003-04-19 02:02:30 +02:00
|
|
|
int lenPos;
|
2003-06-08 19:43:00 +02:00
|
|
|
int endPos;
|
2003-04-19 02:02:30 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/* allow room for message type byte */
|
2003-04-19 02:02:30 +02:00
|
|
|
if (msg_type)
|
2003-06-08 19:43:00 +02:00
|
|
|
endPos = conn->outCount + 1;
|
2003-04-19 02:02:30 +02:00
|
|
|
else
|
2003-06-08 19:43:00 +02:00
|
|
|
endPos = conn->outCount;
|
|
|
|
|
|
|
|
/* do we want a length word? */
|
2021-03-04 09:45:55 +01:00
|
|
|
lenPos = endPos;
|
|
|
|
/* allow room for message length */
|
|
|
|
endPos += 4;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/* make sure there is room for message header */
|
|
|
|
if (pqCheckOutBufferSpace(endPos, conn))
|
2003-04-19 02:02:30 +02:00
|
|
|
return EOF;
|
|
|
|
/* okay, save the message type byte if any */
|
|
|
|
if (msg_type)
|
|
|
|
conn->outBuffer[conn->outCount] = msg_type;
|
|
|
|
/* set up the message pointers */
|
|
|
|
conn->outMsgStart = lenPos;
|
2003-06-08 19:43:00 +02:00
|
|
|
conn->outMsgEnd = endPos;
|
|
|
|
/* length word, if needed, will be filled in by pqPutMsgEnd */
|
2003-04-19 02:02:30 +02:00
|
|
|
|
|
|
|
return 0;
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2003-04-19 02:02:30 +02:00
|
|
|
* pqPutMsgBytes: add bytes to a partially-constructed message
|
|
|
|
*
|
|
|
|
* Returns 0 on success, EOF on error
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pqPutMsgBytes(const void *buf, size_t len, PGconn *conn)
|
|
|
|
{
|
|
|
|
/* make sure there is room for it */
|
2003-04-22 02:08:07 +02:00
|
|
|
if (pqCheckOutBufferSpace(conn->outMsgEnd + len, conn))
|
2003-04-19 02:02:30 +02:00
|
|
|
return EOF;
|
|
|
|
/* okay, save the data */
|
|
|
|
memcpy(conn->outBuffer + conn->outMsgEnd, buf, len);
|
|
|
|
conn->outMsgEnd += len;
|
|
|
|
/* no Pfdebug call here, caller should do it */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pqPutMsgEnd: finish constructing a message and possibly send it
|
|
|
|
*
|
|
|
|
* Returns 0 on success, EOF on error
|
|
|
|
*
|
|
|
|
* We don't actually send anything here unless we've accumulated at least
|
|
|
|
* 8K worth of data (the typical size of a pipe buffer on Unix systems).
|
|
|
|
* This avoids sending small partial packets. The caller must use pqFlush
|
|
|
|
* when it's important to flush all the data out to the server.
|
1999-11-30 04:08:19 +01:00
|
|
|
*/
|
|
|
|
int
|
2003-04-19 02:02:30 +02:00
|
|
|
pqPutMsgEnd(PGconn *conn)
|
1999-11-30 04:08:19 +01:00
|
|
|
{
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Fill in length word if needed */
|
|
|
|
if (conn->outMsgStart >= 0)
|
|
|
|
{
|
|
|
|
uint32 msgLen = conn->outMsgEnd - conn->outMsgStart;
|
|
|
|
|
2017-10-02 00:36:14 +02:00
|
|
|
msgLen = pg_hton32(msgLen);
|
2003-06-08 19:43:00 +02:00
|
|
|
memcpy(conn->outBuffer + conn->outMsgStart, &msgLen, 4);
|
|
|
|
}
|
2003-04-19 02:02:30 +02:00
|
|
|
|
2021-03-31 01:12:34 +02:00
|
|
|
/* trace client-to-server message */
|
|
|
|
if (conn->Pfdebug)
|
|
|
|
{
|
|
|
|
if (conn->outCount < conn->outMsgStart)
|
|
|
|
pqTraceOutputMessage(conn, conn->outBuffer + conn->outCount, true);
|
|
|
|
else
|
|
|
|
pqTraceOutputNoTypeByteMessage(conn,
|
|
|
|
conn->outBuffer + conn->outMsgStart);
|
|
|
|
}
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Make message eligible to send */
|
2003-04-19 02:02:30 +02:00
|
|
|
conn->outCount = conn->outMsgEnd;
|
|
|
|
|
|
|
|
if (conn->outCount >= 8192)
|
|
|
|
{
|
|
|
|
int toSend = conn->outCount - (conn->outCount % 8192);
|
|
|
|
|
|
|
|
if (pqSendSome(conn, toSend) < 0)
|
|
|
|
return EOF;
|
|
|
|
/* in nonblock mode, don't complain if unable to send it all */
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/* ----------
|
|
|
|
* pqReadData: read more data, if any is available
|
1998-05-07 01:51:16 +02:00
|
|
|
* Possible return values:
|
|
|
|
* 1: successfully loaded at least one more byte
|
|
|
|
* 0: no data is presently available, but no error detected
|
|
|
|
* -1: error detected (including EOF = connection closure);
|
|
|
|
* conn->errorMessage set
|
|
|
|
* NOTE: callers must not assume that pointers or indexes into conn->inBuffer
|
|
|
|
* remain valid across this call!
|
2001-08-17 17:11:15 +02:00
|
|
|
* ----------
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
1997-03-16 19:51:29 +01:00
|
|
|
int
|
1998-05-07 01:51:16 +02:00
|
|
|
pqReadData(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1999-09-13 05:00:19 +02:00
|
|
|
int someread = 0;
|
1998-05-07 01:51:16 +02:00
|
|
|
int nread;
|
|
|
|
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock == PGINVALID_SOCKET)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2022-11-15 11:50:04 +01:00
|
|
|
libpq_append_conn_error(conn, "connection not open");
|
1998-05-07 01:51:16 +02:00
|
|
|
return -1;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
/* Left-justify any data in the buffer to make room */
|
|
|
|
if (conn->inStart < conn->inEnd)
|
|
|
|
{
|
2001-05-28 17:29:51 +02:00
|
|
|
if (conn->inStart > 0)
|
|
|
|
{
|
|
|
|
memmove(conn->inBuffer, conn->inBuffer + conn->inStart,
|
|
|
|
conn->inEnd - conn->inStart);
|
|
|
|
conn->inEnd -= conn->inStart;
|
|
|
|
conn->inCursor -= conn->inStart;
|
|
|
|
conn->inStart = 0;
|
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
else
|
2001-05-28 17:29:51 +02:00
|
|
|
{
|
|
|
|
/* buffer is logically empty, reset it */
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->inStart = conn->inCursor = conn->inEnd = 0;
|
2001-05-28 17:29:51 +02:00
|
|
|
}
|
1998-09-01 06:40:42 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
/*
|
|
|
|
* If the buffer is fairly full, enlarge it. We need to be able to enlarge
|
|
|
|
* the buffer in case a single message exceeds the initial buffer size. We
|
|
|
|
* enlarge before filling the buffer entirely so as to avoid asking the
|
|
|
|
* kernel for a partial packet. The magic constant here should be large
|
1999-08-31 03:37:37 +02:00
|
|
|
* enough for a TCP packet or Unix pipe bufferload. 8K is the usual pipe
|
|
|
|
* buffer size, so...
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
1999-08-31 03:37:37 +02:00
|
|
|
if (conn->inBufSize - conn->inEnd < 8192)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2008-05-30 00:02:44 +02:00
|
|
|
if (pqCheckInBufferSpace(conn->inEnd + (size_t) 8192, conn))
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2003-04-22 02:08:07 +02:00
|
|
|
/*
|
|
|
|
* We don't insist that the enlarge worked, but we need some room
|
|
|
|
*/
|
|
|
|
if (conn->inBufSize - conn->inEnd < 100)
|
|
|
|
return -1; /* errorMessage already set */
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
/* OK, try to read some data */
|
2002-04-16 01:34:17 +02:00
|
|
|
retry3:
|
2002-06-16 00:06:09 +02:00
|
|
|
nread = pqsecure_read(conn, conn->inBuffer + conn->inEnd,
|
|
|
|
conn->inBufSize - conn->inEnd);
|
1998-05-07 01:51:16 +02:00
|
|
|
if (nread < 0)
|
|
|
|
{
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
switch (SOCK_ERRNO)
|
|
|
|
{
|
|
|
|
case EINTR:
|
|
|
|
goto retry3;
|
|
|
|
|
|
|
|
/* Some systems return EAGAIN/EWOULDBLOCK for no data */
|
1998-05-07 01:53:48 +02:00
|
|
|
#ifdef EAGAIN
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
case EAGAIN:
|
|
|
|
return someread;
|
1998-05-07 01:53:48 +02:00
|
|
|
#endif
|
|
|
|
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
case EWOULDBLOCK:
|
|
|
|
return someread;
|
1998-09-20 06:51:12 +02:00
|
|
|
#endif
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
|
|
|
|
/* We might get ECONNRESET etc here if connection failed */
|
|
|
|
case ALL_CONNECTION_FAILURE_ERRNOS:
|
|
|
|
goto definitelyFailed;
|
|
|
|
|
|
|
|
default:
|
|
|
|
/* pqsecure_read set the error message for us */
|
|
|
|
return -1;
|
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
if (nread > 0)
|
|
|
|
{
|
|
|
|
conn->inEnd += nread;
|
2000-04-12 19:17:23 +02:00
|
|
|
|
1999-09-13 05:00:19 +02:00
|
|
|
/*
|
|
|
|
* Hack to deal with the fact that some kernels will only give us back
|
|
|
|
* 1 packet per recv() call, even if we asked for more and there is
|
|
|
|
* more available. If it looks like we are reading a long message,
|
|
|
|
* loop back to recv() again immediately, until we run out of data or
|
|
|
|
* buffer space. Without this, the block-and-restart behavior of
|
|
|
|
* libpq's higher levels leads to O(N^2) performance on long messages.
|
|
|
|
*
|
|
|
|
* Since we left-justified the data above, conn->inEnd gives the
|
|
|
|
* amount of data already read in the current message. We consider
|
|
|
|
* the message "long" once we have acquired 32k ...
|
|
|
|
*/
|
|
|
|
if (conn->inEnd > 32768 &&
|
|
|
|
(conn->inBufSize - conn->inEnd) >= 8192)
|
|
|
|
{
|
|
|
|
someread = 1;
|
2002-04-16 01:34:17 +02:00
|
|
|
goto retry3;
|
1999-09-13 05:00:19 +02:00
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
return 1;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-09-13 05:00:19 +02:00
|
|
|
if (someread)
|
|
|
|
return 1; /* got a zero read after successful tries */
|
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
/*
|
|
|
|
* A return value of 0 could mean just that no data is now available, or
|
|
|
|
* it could mean EOF --- that is, the server has closed the connection.
|
|
|
|
* Since we have the socket in nonblock mode, the only way to tell the
|
|
|
|
* difference is to see if select() is saying that the file is ready.
|
|
|
|
* Grumble. Fortunately, we don't expect this path to be taken much,
|
|
|
|
* since in normal practice we should not be trying to read data unless
|
|
|
|
* the file selected for reading already.
|
2003-08-04 19:25:14 +02:00
|
|
|
*
|
|
|
|
* In SSL mode it's even worse: SSL_read() could say WANT_READ and then
|
2014-08-07 11:38:16 +02:00
|
|
|
* data could arrive before we make the pqReadReady() test, but the second
|
|
|
|
* SSL_read() could still say WANT_READ because the data received was not
|
|
|
|
* a complete SSL record. So we must play dumb and assume there is more
|
|
|
|
* data, relying on the SSL layer to detect true EOF.
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
2003-08-04 19:25:14 +02:00
|
|
|
|
|
|
|
#ifdef USE_SSL
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
if (conn->ssl_in_use)
|
2003-08-04 19:25:14 +02:00
|
|
|
return 0;
|
|
|
|
#endif
|
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
switch (pqReadReady(conn))
|
|
|
|
{
|
|
|
|
case 0:
|
|
|
|
/* definitely no data available */
|
|
|
|
return 0;
|
|
|
|
case 1:
|
|
|
|
/* ready for read */
|
|
|
|
break;
|
|
|
|
default:
|
2014-10-23 00:41:44 +02:00
|
|
|
/* we override pqReadReady's message with something more useful */
|
|
|
|
goto definitelyEOF;
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Still not sure that it's EOF, because some data could have just
|
|
|
|
* arrived.
|
|
|
|
*/
|
2002-04-16 01:34:17 +02:00
|
|
|
retry4:
|
2002-06-16 00:06:09 +02:00
|
|
|
nread = pqsecure_read(conn, conn->inBuffer + conn->inEnd,
|
|
|
|
conn->inBufSize - conn->inEnd);
|
1998-05-07 01:51:16 +02:00
|
|
|
if (nread < 0)
|
|
|
|
{
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
switch (SOCK_ERRNO)
|
|
|
|
{
|
|
|
|
case EINTR:
|
|
|
|
goto retry4;
|
|
|
|
|
|
|
|
/* Some systems return EAGAIN/EWOULDBLOCK for no data */
|
1998-05-07 01:53:48 +02:00
|
|
|
#ifdef EAGAIN
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
case EAGAIN:
|
|
|
|
return 0;
|
1998-05-07 01:53:48 +02:00
|
|
|
#endif
|
|
|
|
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
case EWOULDBLOCK:
|
|
|
|
return 0;
|
1998-05-07 01:53:48 +02:00
|
|
|
#endif
|
Recognize network-failure errnos as indicating hard connection loss.
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places)
received special treatment in our error handling logic. This patch
changes things so that related error codes such as ECONNABORTED are
also recognized as indicating that the connection's dead and unlikely
to come back.
We continue to think, however, that only ECONNRESET and EPIPE should be
reported as probable server crashes; the other cases indicate network
connectivity problems but prove little about the server's state. Thus,
there's no change in the error message texts that are output for such
cases. The key practical effect is that errcode_for_socket_access()
will report ERRCODE_CONNECTION_FAILURE rather than
ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this
will fix buildfarm member lorikeet's failures since commit 32a9c0bdf,
as that seems to be due to not treating ECONNABORTED equivalently to
ECONNRESET.
The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN,
EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these
were second-class citizens in terms of their handling in places like
get_errno_symbol(), so upgrade the infrastructure where necessary.
As committed, this patch assumes that all these symbols are defined
everywhere. POSIX specifies all of them except EHOSTDOWN, but that
seems to exist on all platforms of interest; we'll see what the
buildfarm says about that.
Probably this should be back-patched, but let's see what the buildfarm
thinks of it first.
Fujii Masao and Tom Lane
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-10-10 19:28:12 +02:00
|
|
|
|
|
|
|
/* We might get ECONNRESET etc here if connection failed */
|
|
|
|
case ALL_CONNECTION_FAILURE_ERRNOS:
|
|
|
|
goto definitelyFailed;
|
|
|
|
|
|
|
|
default:
|
|
|
|
/* pqsecure_read set the error message for us */
|
|
|
|
return -1;
|
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
if (nread > 0)
|
|
|
|
{
|
|
|
|
conn->inEnd += nread;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* OK, we are getting a zero read even though select() says ready. This
|
2014-10-23 00:41:44 +02:00
|
|
|
* means the connection has been closed. Cope.
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
2014-10-23 00:41:44 +02:00
|
|
|
definitelyEOF:
|
2022-11-15 11:50:04 +01:00
|
|
|
libpq_append_conn_error(conn, "server closed the connection unexpectedly\n"
|
|
|
|
"\tThis probably means the server terminated abnormally\n"
|
|
|
|
"\tbefore or while processing the request.");
|
2014-10-23 00:41:44 +02:00
|
|
|
|
|
|
|
/* Come here if lower-level code already set a suitable errorMessage */
|
1998-09-20 06:51:12 +02:00
|
|
|
definitelyFailed:
|
2015-11-12 19:03:52 +01:00
|
|
|
/* Do *not* drop any already-read data; caller still wants it */
|
|
|
|
pqDropConnection(conn, false);
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->status = CONNECTION_BAD; /* No more connection to backend */
|
|
|
|
return -1;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2002-03-05 07:07:27 +01:00
|
|
|
/*
|
2003-04-19 02:02:30 +02:00
|
|
|
* pqSendSome: send data waiting in the output buffer.
|
|
|
|
*
|
|
|
|
* len is how much to try to send (typically equal to outCount, but may
|
|
|
|
* be less).
|
2002-03-05 06:20:12 +01:00
|
|
|
*
|
2003-04-19 02:02:30 +02:00
|
|
|
* Return 0 on success, -1 on failure and 1 when not all data could be sent
|
|
|
|
* because the socket would block and the connection is non-blocking.
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
*
|
Try to read data from the socket in pqSendSome's write_failed paths.
Even when we've concluded that we have a hard write failure on the
socket, we should continue to try to read data. This gives us an
opportunity to collect any final error message that the backend might
have sent before closing the connection; moreover it is the job of
pqReadData not pqSendSome to close the socket once EOF is detected.
Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect
data in the case where we'd already set write_failed. The problem was
masked for ordinary query operations (which really only make one write
attempt anyway), but COPY to the server would continue to send data
indefinitely after a mid-COPY connection loss.
Hence, add pqReadData calls into the paths where pqSendSome drops data
because of write_failed. If we've lost the connection, this will
eventually result in closing the socket and setting CONNECTION_BAD,
which will cause PQputline and siblings to report failure, allowing
the application to terminate the COPY sooner. (Basically this restores
what happened before 1f39a1c06.)
There are related issues that this does not solve; for example, if the
backend sends an error but doesn't drop the connection, we did and
still will keep pumping COPY data as long as the application sends it.
Fixing that will require application-visible behavior changes though,
and anyway it's an ancient behavior that we've had few complaints about.
For now I'm just trying to fix the regression from 1f39a1c06.
Per a complaint from Andres Freund. Back-patch into v12 where
1f39a1c06 came in.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:44:13 +02:00
|
|
|
* Note that this is also responsible for consuming data from the socket
|
|
|
|
* (putting it in conn->inBuffer) in any situation where we can't send
|
|
|
|
* all the specified data immediately.
|
|
|
|
*
|
2022-02-12 20:00:09 +01:00
|
|
|
* If a socket-level write failure occurs, conn->write_failed is set and the
|
|
|
|
* error message is saved in conn->write_err_msg, but we clear the output
|
|
|
|
* buffer and return zero anyway; this is because callers should soldier on
|
|
|
|
* until we have read what we can from the server and checked for an error
|
|
|
|
* message. write_err_msg should be reported only when we are unable to
|
|
|
|
* obtain a server error first. Much of that behavior is implemented at
|
|
|
|
* lower levels, but this function deals with some edge cases.
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
2003-04-19 02:02:30 +02:00
|
|
|
static int
|
|
|
|
pqSendSome(PGconn *conn, int len)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-05-07 01:51:16 +02:00
|
|
|
char *ptr = conn->outBuffer;
|
2003-04-19 02:02:30 +02:00
|
|
|
int remaining = conn->outCount;
|
|
|
|
int result = 0;
|
1998-05-07 01:51:16 +02:00
|
|
|
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
/*
|
|
|
|
* If we already had a write failure, we will never again try to send data
|
|
|
|
* on that connection. Even if the kernel would let us, we've probably
|
|
|
|
* lost message boundary sync with the server. conn->write_failed
|
|
|
|
* therefore persists until the connection is reset, and we just discard
|
Try to read data from the socket in pqSendSome's write_failed paths.
Even when we've concluded that we have a hard write failure on the
socket, we should continue to try to read data. This gives us an
opportunity to collect any final error message that the backend might
have sent before closing the connection; moreover it is the job of
pqReadData not pqSendSome to close the socket once EOF is detected.
Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect
data in the case where we'd already set write_failed. The problem was
masked for ordinary query operations (which really only make one write
attempt anyway), but COPY to the server would continue to send data
indefinitely after a mid-COPY connection loss.
Hence, add pqReadData calls into the paths where pqSendSome drops data
because of write_failed. If we've lost the connection, this will
eventually result in closing the socket and setting CONNECTION_BAD,
which will cause PQputline and siblings to report failure, allowing
the application to terminate the COPY sooner. (Basically this restores
what happened before 1f39a1c06.)
There are related issues that this does not solve; for example, if the
backend sends an error but doesn't drop the connection, we did and
still will keep pumping COPY data as long as the application sends it.
Fixing that will require application-visible behavior changes though,
and anyway it's an ancient behavior that we've had few complaints about.
For now I'm just trying to fix the regression from 1f39a1c06.
Per a complaint from Andres Freund. Back-patch into v12 where
1f39a1c06 came in.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:44:13 +02:00
|
|
|
* all data presented to be written. However, as long as we still have a
|
|
|
|
* valid socket, we should continue to absorb data from the backend, so
|
|
|
|
* that we can collect any final error messages.
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
*/
|
|
|
|
if (conn->write_failed)
|
|
|
|
{
|
|
|
|
/* conn->write_err_msg should be set up already */
|
|
|
|
conn->outCount = 0;
|
Try to read data from the socket in pqSendSome's write_failed paths.
Even when we've concluded that we have a hard write failure on the
socket, we should continue to try to read data. This gives us an
opportunity to collect any final error message that the backend might
have sent before closing the connection; moreover it is the job of
pqReadData not pqSendSome to close the socket once EOF is detected.
Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect
data in the case where we'd already set write_failed. The problem was
masked for ordinary query operations (which really only make one write
attempt anyway), but COPY to the server would continue to send data
indefinitely after a mid-COPY connection loss.
Hence, add pqReadData calls into the paths where pqSendSome drops data
because of write_failed. If we've lost the connection, this will
eventually result in closing the socket and setting CONNECTION_BAD,
which will cause PQputline and siblings to report failure, allowing
the application to terminate the COPY sooner. (Basically this restores
what happened before 1f39a1c06.)
There are related issues that this does not solve; for example, if the
backend sends an error but doesn't drop the connection, we did and
still will keep pumping COPY data as long as the application sends it.
Fixing that will require application-visible behavior changes though,
and anyway it's an ancient behavior that we've had few complaints about.
For now I'm just trying to fix the regression from 1f39a1c06.
Per a complaint from Andres Freund. Back-patch into v12 where
1f39a1c06 came in.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:44:13 +02:00
|
|
|
/* Absorb input data if any, and detect socket closure */
|
|
|
|
if (conn->sock != PGINVALID_SOCKET)
|
|
|
|
{
|
|
|
|
if (pqReadData(conn) < 0)
|
|
|
|
return -1;
|
|
|
|
}
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock == PGINVALID_SOCKET)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
conn->write_failed = true;
|
2022-02-12 20:00:09 +01:00
|
|
|
/* Store error message in conn->write_err_msg, if possible */
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
/* (strdup failure is OK, we'll cope later) */
|
In libpq, always append new error messages to conn->errorMessage.
Previously, we had an undisciplined mish-mash of printfPQExpBuffer and
appendPQExpBuffer calls to report errors within libpq. This commit
establishes a uniform rule that appendPQExpBuffer[Str] should be used.
conn->errorMessage is reset only at the start of an application request,
and then accumulates messages till we're done. We can remove no less
than three different ad-hoc mechanisms that were used to get the effect
of concatenation of error messages within a sequence of operations.
Although this makes things quite a bit cleaner conceptually, the main
reason to do it is to make the world safer for the multiple-target-host
feature that was added awhile back. Previously, there were many cases
in which an error occurring during an individual host connection attempt
would wipe out the record of what had happened during previous attempts.
(The reporting is still inadequate, in that it can be hard to tell which
host got the failure, but that seems like a matter for a separate commit.)
Currently, lo_import and lo_export contain exceptions to the "never
use printfPQExpBuffer" rule. If we changed them, we'd risk reporting
an incidental lo_close failure before the actual read or write
failure, which would be confusing, not least because lo_close happened
after the main failure. We could improve this by inventing an
internal version of lo_close that doesn't reset the errorMessage; but
we'd also need a version of PQfn() that does that, and it didn't quite
seem worth the trouble for now.
Discussion: https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com
2021-01-11 19:12:09 +01:00
|
|
|
conn->write_err_msg = strdup(libpq_gettext("connection not open\n"));
|
2014-02-12 23:50:07 +01:00
|
|
|
/* Discard queued data; no chance it'll ever be sent */
|
|
|
|
conn->outCount = 0;
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
return 0;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
1997-03-16 19:51:29 +01:00
|
|
|
|
2000-01-18 07:09:24 +01:00
|
|
|
/* while there's still data to send */
|
1998-05-07 01:51:16 +02:00
|
|
|
while (len > 0)
|
|
|
|
{
|
1999-09-27 05:13:16 +02:00
|
|
|
int sent;
|
2000-01-18 07:09:24 +01:00
|
|
|
|
2008-08-20 13:53:45 +02:00
|
|
|
#ifndef WIN32
|
2002-06-16 00:06:09 +02:00
|
|
|
sent = pqsecure_write(conn, ptr, len);
|
2008-08-20 13:53:45 +02:00
|
|
|
#else
|
2009-06-11 16:49:15 +02:00
|
|
|
|
2008-08-20 13:53:45 +02:00
|
|
|
/*
|
|
|
|
* Windows can fail on large sends, per KB article Q201213. The
|
|
|
|
* failure-point appears to be different in different versions of
|
|
|
|
* Windows, but 64k should always be safe.
|
|
|
|
*/
|
|
|
|
sent = pqsecure_write(conn, ptr, Min(len, 65536));
|
|
|
|
#endif
|
1998-08-17 05:50:43 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
if (sent < 0)
|
|
|
|
{
|
2011-07-25 05:29:03 +02:00
|
|
|
/* Anything except EAGAIN/EWOULDBLOCK/EINTR is trouble */
|
2001-08-21 22:39:54 +02:00
|
|
|
switch (SOCK_ERRNO)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
|
|
|
#ifdef EAGAIN
|
|
|
|
case EAGAIN:
|
|
|
|
break;
|
|
|
|
#endif
|
|
|
|
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
|
|
|
|
case EWOULDBLOCK:
|
|
|
|
break;
|
|
|
|
#endif
|
2000-01-18 07:09:24 +01:00
|
|
|
case EINTR:
|
|
|
|
continue;
|
1999-05-28 03:54:53 +02:00
|
|
|
|
2011-07-25 05:29:03 +02:00
|
|
|
default:
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
/* Discard queued data; no chance it'll ever be sent */
|
2003-04-19 02:02:30 +02:00
|
|
|
conn->outCount = 0;
|
Try to read data from the socket in pqSendSome's write_failed paths.
Even when we've concluded that we have a hard write failure on the
socket, we should continue to try to read data. This gives us an
opportunity to collect any final error message that the backend might
have sent before closing the connection; moreover it is the job of
pqReadData not pqSendSome to close the socket once EOF is detected.
Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect
data in the case where we'd already set write_failed. The problem was
masked for ordinary query operations (which really only make one write
attempt anyway), but COPY to the server would continue to send data
indefinitely after a mid-COPY connection loss.
Hence, add pqReadData calls into the paths where pqSendSome drops data
because of write_failed. If we've lost the connection, this will
eventually result in closing the socket and setting CONNECTION_BAD,
which will cause PQputline and siblings to report failure, allowing
the application to terminate the COPY sooner. (Basically this restores
what happened before 1f39a1c06.)
There are related issues that this does not solve; for example, if the
backend sends an error but doesn't drop the connection, we did and
still will keep pumping COPY data as long as the application sends it.
Fixing that will require application-visible behavior changes though,
and anyway it's an ancient behavior that we've had few complaints about.
For now I'm just trying to fix the regression from 1f39a1c06.
Per a complaint from Andres Freund. Back-patch into v12 where
1f39a1c06 came in.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:44:13 +02:00
|
|
|
|
|
|
|
/* Absorb input data if any, and detect socket closure */
|
|
|
|
if (conn->sock != PGINVALID_SOCKET)
|
|
|
|
{
|
|
|
|
if (pqReadData(conn) < 0)
|
|
|
|
return -1;
|
|
|
|
}
|
2022-02-12 20:00:09 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Lower-level code should already have filled
|
|
|
|
* conn->write_err_msg (and set conn->write_failed) or
|
|
|
|
* conn->errorMessage. In the former case, we pretend
|
|
|
|
* there's no problem; the write_failed condition will be
|
|
|
|
* dealt with later. Otherwise, report the error now.
|
|
|
|
*/
|
|
|
|
if (conn->write_failed)
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return -1;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ptr += sent;
|
|
|
|
len -= sent;
|
2003-04-19 02:02:30 +02:00
|
|
|
remaining -= sent;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
2000-01-18 07:09:24 +01:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
if (len > 0)
|
|
|
|
{
|
2000-01-18 07:09:24 +01:00
|
|
|
/*
|
2003-06-21 23:51:35 +02:00
|
|
|
* We didn't send it all, wait till we can send more.
|
|
|
|
*
|
2003-10-19 23:36:41 +02:00
|
|
|
* There are scenarios in which we can't send data because the
|
|
|
|
* communications channel is full, but we cannot expect the server
|
|
|
|
* to clear the channel eventually because it's blocked trying to
|
|
|
|
* send data to us. (This can happen when we are sending a large
|
|
|
|
* amount of COPY data, and the server has generated lots of
|
|
|
|
* NOTICE responses.) To avoid a deadlock situation, we must be
|
|
|
|
* prepared to accept and buffer incoming data before we try
|
|
|
|
* again. Furthermore, it is possible that such incoming data
|
|
|
|
* might not arrive until after we've gone to sleep. Therefore,
|
|
|
|
* we wait for either read ready or write ready.
|
Fix potential deadlock with libpq non-blocking mode.
If libpq output buffer is full, pqSendSome() function tries to drain any
incoming data. This avoids deadlock, if the server e.g. sends a lot of
NOTICE messages, and blocks until we read them. However, pqSendSome() only
did that in blocking mode. In non-blocking mode, the deadlock could still
happen.
To fix, take a two-pronged approach:
1. Change the documentation to instruct that when PQflush() returns 1, you
should wait for both read- and write-ready, and call PQconsumeInput() if it
becomes read-ready. That fixes the deadlock, but applications are not going
to change overnight.
2. In pqSendSome(), drain the input buffer before returning 1. This
alleviates the problem for applications that only wait for write-ready. In
particular, a slow but steady stream of NOTICE messages during COPY FROM
STDIN will no longer cause a deadlock. The risk remains that the server
attempts to send a large burst of data and fills its output buffer, and at
the same time the client also sends enough data to fill its output buffer.
The application will deadlock if it goes to sleep, waiting for the socket
to become write-ready, before the server's data arrives. In practice,
NOTICE messages and such that the server might be sending are usually
short, so it's highly unlikely that the server would fill its output buffer
so quickly.
Backpatch to all supported versions.
2015-02-23 12:32:34 +01:00
|
|
|
*
|
|
|
|
* In non-blocking mode, we don't wait here directly, but return 1
|
|
|
|
* to indicate that data is still pending. The caller should wait
|
|
|
|
* for both read and write ready conditions, and call
|
|
|
|
* PQconsumeInput() on read ready, but just in case it doesn't, we
|
|
|
|
* call pqReadData() ourselves before returning. That's not
|
|
|
|
* enough if the data has not arrived yet, but it's the best we
|
|
|
|
* can do, and works pretty well in practice. (The documentation
|
|
|
|
* used to say that you only need to wait for write-ready, so
|
|
|
|
* there are still plenty of applications like that out there.)
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
*
|
|
|
|
* Note that errors here don't result in write_failed becoming
|
|
|
|
* set.
|
2003-10-19 23:36:41 +02:00
|
|
|
*/
|
|
|
|
if (pqReadData(conn) < 0)
|
|
|
|
{
|
|
|
|
result = -1; /* error message already set up */
|
|
|
|
break;
|
|
|
|
}
|
Fix potential deadlock with libpq non-blocking mode.
If libpq output buffer is full, pqSendSome() function tries to drain any
incoming data. This avoids deadlock, if the server e.g. sends a lot of
NOTICE messages, and blocks until we read them. However, pqSendSome() only
did that in blocking mode. In non-blocking mode, the deadlock could still
happen.
To fix, take a two-pronged approach:
1. Change the documentation to instruct that when PQflush() returns 1, you
should wait for both read- and write-ready, and call PQconsumeInput() if it
becomes read-ready. That fixes the deadlock, but applications are not going
to change overnight.
2. In pqSendSome(), drain the input buffer before returning 1. This
alleviates the problem for applications that only wait for write-ready. In
particular, a slow but steady stream of NOTICE messages during COPY FROM
STDIN will no longer cause a deadlock. The risk remains that the server
attempts to send a large burst of data and fills its output buffer, and at
the same time the client also sends enough data to fill its output buffer.
The application will deadlock if it goes to sleep, waiting for the socket
to become write-ready, before the server's data arrives. In practice,
NOTICE messages and such that the server might be sending are usually
short, so it's highly unlikely that the server would fill its output buffer
so quickly.
Backpatch to all supported versions.
2015-02-23 12:32:34 +01:00
|
|
|
|
|
|
|
if (pqIsnonblocking(conn))
|
|
|
|
{
|
|
|
|
result = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
if (pqWait(true, true, conn))
|
2003-04-19 02:02:30 +02:00
|
|
|
{
|
|
|
|
result = -1;
|
|
|
|
break;
|
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/* shift the remaining contents of the buffer */
|
|
|
|
if (remaining > 0)
|
|
|
|
memmove(conn->outBuffer, ptr, remaining);
|
|
|
|
conn->outCount = remaining;
|
1998-05-07 01:51:16 +02:00
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1996-12-31 08:29:17 +01:00
|
|
|
|
2002-03-05 06:20:12 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pqFlush: send any data waiting in the output buffer
|
|
|
|
*
|
2003-04-19 02:02:30 +02:00
|
|
|
* Return 0 on success, -1 on failure and 1 when not all data could be sent
|
|
|
|
* because the socket would block and the connection is non-blocking.
|
Restructure libpq's handling of send failures.
Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
2019-03-19 21:20:20 +01:00
|
|
|
* (See pqSendSome comments about how failure should be handled.)
|
2002-03-05 06:20:12 +01:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
pqFlush(PGconn *conn)
|
|
|
|
{
|
2003-04-19 02:02:30 +02:00
|
|
|
if (conn->outCount > 0)
|
2021-03-31 01:12:34 +02:00
|
|
|
{
|
|
|
|
if (conn->Pfdebug)
|
|
|
|
fflush(conn->Pfdebug);
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
return pqSendSome(conn, conn->outCount);
|
2021-03-31 01:12:34 +02:00
|
|
|
}
|
2003-04-19 02:02:30 +02:00
|
|
|
|
2002-03-05 06:20:12 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
|
|
|
* pqWait: wait until we can read or write the connection socket
|
2001-04-01 01:13:30 +02:00
|
|
|
*
|
2002-06-15 22:01:31 +02:00
|
|
|
* JAB: If SSL enabled and used and forRead, buffered bytes short-circuit the
|
|
|
|
* call to select().
|
|
|
|
*
|
2001-04-01 01:13:30 +02:00
|
|
|
* We also stop waiting and return if the kernel flags an exception condition
|
|
|
|
* on the socket. The actual error condition will be detected and reported
|
|
|
|
* when the caller tries to read or write the socket.
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
pqWait(int forRead, int forWrite, PGconn *conn)
|
2002-08-17 14:33:18 +02:00
|
|
|
{
|
2002-10-25 01:35:55 +02:00
|
|
|
return pqWaitTimed(forRead, forWrite, conn, (time_t) -1);
|
2002-08-17 14:33:18 +02:00
|
|
|
}
|
|
|
|
|
2002-10-25 01:35:55 +02:00
|
|
|
/*
|
|
|
|
* pqWaitTimed: wait, but not past finish_time.
|
|
|
|
*
|
|
|
|
* finish_time = ((time_t) -1) disables the wait limit.
|
2017-05-19 22:19:51 +02:00
|
|
|
*
|
|
|
|
* Returns -1 on failure, 0 if the socket is readable/writable, 1 if it timed out.
|
2002-10-25 01:35:55 +02:00
|
|
|
*/
|
2002-08-17 14:33:18 +02:00
|
|
|
int
|
2002-10-16 04:55:30 +02:00
|
|
|
pqWaitTimed(int forRead, int forWrite, PGconn *conn, time_t finish_time)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2003-03-06 04:16:55 +01:00
|
|
|
int result;
|
2002-08-17 14:33:18 +02:00
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
result = pqSocketCheck(conn, forRead, forWrite, finish_time);
|
|
|
|
|
|
|
|
if (result < 0)
|
2017-05-19 22:19:51 +02:00
|
|
|
return -1; /* errorMessage is already set */
|
2003-03-06 04:16:55 +01:00
|
|
|
|
|
|
|
if (result == 0)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2022-11-15 11:50:04 +01:00
|
|
|
libpq_append_conn_error(conn, "timeout expired");
|
2017-05-19 22:19:51 +02:00
|
|
|
return 1;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/*
|
|
|
|
* pqReadReady: is select() saying the file is ready to read?
|
|
|
|
* Returns -1 on failure, 0 if not ready, 1 if ready.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pqReadReady(PGconn *conn)
|
|
|
|
{
|
|
|
|
return pqSocketCheck(conn, 1, 0, (time_t) 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pqWriteReady: is select() saying the file is ready to write?
|
|
|
|
* Returns -1 on failure, 0 if not ready, 1 if ready.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pqWriteReady(PGconn *conn)
|
|
|
|
{
|
|
|
|
return pqSocketCheck(conn, 0, 1, (time_t) 0);
|
|
|
|
}
|
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
/*
|
|
|
|
* Checks a socket, using poll or select, for data to be read, written,
|
|
|
|
* or both. Returns >0 if one or more conditions are met, 0 if it timed
|
|
|
|
* out, -1 if an error occurred.
|
2003-04-19 02:02:30 +02:00
|
|
|
*
|
2003-03-06 04:16:55 +01:00
|
|
|
* If SSL is in use, the SSL buffer is checked prior to checking the socket
|
|
|
|
* for read data directly.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pqSocketCheck(PGconn *conn, int forRead, int forWrite, time_t end_time)
|
|
|
|
{
|
|
|
|
int result;
|
|
|
|
|
|
|
|
if (!conn)
|
|
|
|
return -1;
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock == PGINVALID_SOCKET)
|
2003-03-06 04:16:55 +01:00
|
|
|
{
|
2022-11-15 11:50:04 +01:00
|
|
|
libpq_append_conn_error(conn, "invalid socket");
|
2003-03-06 04:16:55 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-12-01 16:43:14 +01:00
|
|
|
#ifdef USE_SSL
|
2003-04-19 02:02:30 +02:00
|
|
|
/* Check for SSL library buffering read bytes */
|
2019-05-13 16:53:19 +02:00
|
|
|
if (forRead && conn->ssl_in_use && pgtls_read_pending(conn))
|
2002-06-15 22:01:31 +02:00
|
|
|
{
|
|
|
|
/* short-circuit the select */
|
2003-03-06 04:16:55 +01:00
|
|
|
return 1;
|
2002-06-15 22:01:31 +02:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
/* We will retry as long as we get EINTR */
|
|
|
|
do
|
|
|
|
result = pqSocketPoll(conn->sock, forRead, forWrite, end_time);
|
|
|
|
while (result < 0 && SOCK_ERRNO == EINTR);
|
2002-10-25 01:35:55 +02:00
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
if (result < 0)
|
|
|
|
{
|
2018-09-26 18:35:57 +02:00
|
|
|
char sebuf[PG_STRERROR_R_BUFLEN];
|
2003-06-14 19:49:54 +02:00
|
|
|
|
2022-11-15 11:50:04 +01:00
|
|
|
libpq_append_conn_error(conn, "%s() failed: %s", "select",
|
2003-06-14 19:49:54 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
return result;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
2000-01-29 17:58:54 +01:00
|
|
|
|
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
/*
|
|
|
|
* Check a file descriptor for read and/or write data, possibly waiting.
|
|
|
|
* If neither forRead nor forWrite are set, immediately return a timeout
|
|
|
|
* condition (without waiting). Return >0 if condition is met, 0
|
|
|
|
* if a timeout occurred, -1 if an error or interrupt occurred.
|
2003-04-19 02:02:30 +02:00
|
|
|
*
|
2003-03-06 04:16:55 +01:00
|
|
|
* Timeout is infinite if end_time is -1. Timeout is immediate (no blocking)
|
|
|
|
* if end_time is 0 (or indeed, any time before now).
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pqSocketPoll(int sock, int forRead, int forWrite, time_t end_time)
|
|
|
|
{
|
|
|
|
/* We use poll(2) if available, otherwise select(2) */
|
|
|
|
#ifdef HAVE_POLL
|
|
|
|
struct pollfd input_fd;
|
|
|
|
int timeout_ms;
|
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
if (!forRead && !forWrite)
|
|
|
|
return 0;
|
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
input_fd.fd = sock;
|
2003-04-19 02:02:30 +02:00
|
|
|
input_fd.events = POLLERR;
|
2003-03-06 04:16:55 +01:00
|
|
|
input_fd.revents = 0;
|
|
|
|
|
|
|
|
if (forRead)
|
|
|
|
input_fd.events |= POLLIN;
|
|
|
|
if (forWrite)
|
|
|
|
input_fd.events |= POLLOUT;
|
|
|
|
|
|
|
|
/* Compute appropriate timeout interval */
|
|
|
|
if (end_time == ((time_t) -1))
|
|
|
|
timeout_ms = -1;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
time_t now = time(NULL);
|
|
|
|
|
|
|
|
if (end_time > now)
|
|
|
|
timeout_ms = (end_time - now) * 1000;
|
|
|
|
else
|
|
|
|
timeout_ms = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return poll(&input_fd, 1, timeout_ms);
|
|
|
|
#else /* !HAVE_POLL */
|
|
|
|
|
|
|
|
fd_set input_mask;
|
|
|
|
fd_set output_mask;
|
|
|
|
fd_set except_mask;
|
|
|
|
struct timeval timeout;
|
|
|
|
struct timeval *ptr_timeout;
|
|
|
|
|
|
|
|
if (!forRead && !forWrite)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
FD_ZERO(&input_mask);
|
|
|
|
FD_ZERO(&output_mask);
|
|
|
|
FD_ZERO(&except_mask);
|
|
|
|
if (forRead)
|
|
|
|
FD_SET(sock, &input_mask);
|
2009-06-11 16:49:15 +02:00
|
|
|
|
2003-03-06 04:16:55 +01:00
|
|
|
if (forWrite)
|
|
|
|
FD_SET(sock, &output_mask);
|
|
|
|
FD_SET(sock, &except_mask);
|
|
|
|
|
|
|
|
/* Compute appropriate timeout interval */
|
|
|
|
if (end_time == ((time_t) -1))
|
|
|
|
ptr_timeout = NULL;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
time_t now = time(NULL);
|
|
|
|
|
|
|
|
if (end_time > now)
|
|
|
|
timeout.tv_sec = end_time - now;
|
|
|
|
else
|
|
|
|
timeout.tv_sec = 0;
|
|
|
|
timeout.tv_usec = 0;
|
|
|
|
ptr_timeout = &timeout;
|
|
|
|
}
|
|
|
|
|
|
|
|
return select(sock + 1, &input_mask, &output_mask,
|
|
|
|
&except_mask, ptr_timeout);
|
|
|
|
#endif /* HAVE_POLL */
|
|
|
|
}
|
|
|
|
|
2000-01-29 17:58:54 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A couple of "miscellaneous" multibyte related functions. They used
|
|
|
|
* to be in fe-print.c but that file is doomed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
* Returns the byte length of the character beginning at s, using the
|
2000-01-29 17:58:54 +01:00
|
|
|
* specified encoding.
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
*
|
|
|
|
* Caution: when dealing with text that is not certainly valid in the
|
|
|
|
* specified encoding, the result may exceed the actual remaining
|
|
|
|
* string length. Callers that are not prepared to deal with that
|
|
|
|
* should use PQmblenBounded() instead.
|
2000-01-29 17:58:54 +01:00
|
|
|
*/
|
|
|
|
int
|
2005-09-24 19:53:28 +02:00
|
|
|
PQmblen(const char *s, int encoding)
|
2000-01-29 17:58:54 +01:00
|
|
|
{
|
2006-01-11 09:43:13 +01:00
|
|
|
return pg_encoding_mblen(encoding, s);
|
2000-01-29 17:58:54 +01:00
|
|
|
}
|
|
|
|
|
2004-03-15 11:41:26 +01:00
|
|
|
/*
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
* Returns the byte length of the character beginning at s, using the
|
|
|
|
* specified encoding; but not more than the distance to end of string.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
PQmblenBounded(const char *s, int encoding)
|
|
|
|
{
|
|
|
|
return strnlen(s, pg_encoding_mblen(encoding, s));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns the display length of the character beginning at s, using the
|
2004-03-15 11:41:26 +01:00
|
|
|
* specified encoding.
|
|
|
|
*/
|
|
|
|
int
|
2005-09-24 19:53:28 +02:00
|
|
|
PQdsplen(const char *s, int encoding)
|
2004-03-15 11:41:26 +01:00
|
|
|
{
|
2006-01-11 09:43:13 +01:00
|
|
|
return pg_encoding_dsplen(encoding, s);
|
2004-03-15 11:41:26 +01:00
|
|
|
}
|
|
|
|
|
2000-01-29 17:58:54 +01:00
|
|
|
/*
|
|
|
|
* Get encoding id from environment variable PGCLIENTENCODING.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
PQenv2encoding(void)
|
|
|
|
{
|
|
|
|
char *str;
|
Commit Karel's patch.
-------------------------------------------------------------------
Subject: Re: [PATCHES] encoding names
From: Karel Zak <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Date: Fri, 31 Aug 2001 17:24:38 +0200
On Thu, Aug 30, 2001 at 01:30:40AM +0200, Peter Eisentraut wrote:
> > - convert encoding 'name' to 'id'
>
> I thought we decided not to add functions returning "new" names until we
> know exactly what the new names should be, and pending schema
Ok, the patch not to add functions.
> better
>
> ...(): encoding name too long
Fixed.
I found new bug in command/variable.c in parse_client_encoding(), nobody
probably never see this error:
if (pg_set_client_encoding(encoding))
{
elog(ERROR, "Conversion between %s and %s is not supported",
value, GetDatabaseEncodingName());
}
because pg_set_client_encoding() returns -1 for error and 0 as true.
It's fixed too.
IMHO it can be apply.
Karel
PS:
* following files are renamed:
src/utils/mb/Unicode/KOI8_to_utf8.map -->
src/utils/mb/Unicode/koi8r_to_utf8.map
src/utils/mb/Unicode/WIN_to_utf8.map -->
src/utils/mb/Unicode/win1251_to_utf8.map
src/utils/mb/Unicode/utf8_to_KOI8.map -->
src/utils/mb/Unicode/utf8_to_koi8r.map
src/utils/mb/Unicode/utf8_to_WIN.map -->
src/utils/mb/Unicode/utf8_to_win1251.map
* new file:
src/utils/mb/encname.c
* removed file:
src/utils/mb/common.c
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
2001-09-06 06:57:30 +02:00
|
|
|
int encoding = PG_SQL_ASCII;
|
2000-01-29 17:58:54 +01:00
|
|
|
|
|
|
|
str = getenv("PGCLIENTENCODING");
|
|
|
|
if (str && *str != '\0')
|
2007-10-13 22:18:42 +02:00
|
|
|
{
|
2000-01-29 17:58:54 +01:00
|
|
|
encoding = pg_char_to_encoding(str);
|
2007-10-13 22:18:42 +02:00
|
|
|
if (encoding < 0)
|
|
|
|
encoding = PG_SQL_ASCII;
|
|
|
|
}
|
2006-01-11 09:43:13 +01:00
|
|
|
return encoding;
|
2000-01-29 17:58:54 +01:00
|
|
|
}
|
|
|
|
|
2001-07-15 15:45:04 +02:00
|
|
|
|
|
|
|
#ifdef ENABLE_NLS
|
2003-03-06 04:16:55 +01:00
|
|
|
|
2014-09-12 16:12:11 +02:00
|
|
|
static void
|
2020-05-21 17:31:16 +02:00
|
|
|
libpq_binddomain(void)
|
2001-07-15 15:45:04 +02:00
|
|
|
{
|
2022-01-21 21:36:12 +01:00
|
|
|
/*
|
2024-02-09 17:21:08 +01:00
|
|
|
* At least on Windows, there are gettext implementations that fail if
|
|
|
|
* multiple threads call bindtextdomain() concurrently. Use a mutex and
|
|
|
|
* flag variable to ensure that we call it just once per process. It is
|
|
|
|
* not known that similar bugs exist on non-Windows platforms, but we
|
|
|
|
* might as well do it the same way everywhere.
|
2022-01-21 21:36:12 +01:00
|
|
|
*/
|
|
|
|
static volatile bool already_bound = false;
|
2024-02-09 17:21:08 +01:00
|
|
|
static pthread_mutex_t binddomain_mutex = PTHREAD_MUTEX_INITIALIZER;
|
2001-07-15 15:45:04 +02:00
|
|
|
|
|
|
|
if (!already_bound)
|
|
|
|
{
|
2014-09-12 16:12:11 +02:00
|
|
|
/* bindtextdomain() does not preserve errno */
|
2005-08-23 23:02:05 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
int save_errno = GetLastError();
|
|
|
|
#else
|
|
|
|
int save_errno = errno;
|
|
|
|
#endif
|
2024-02-09 17:21:08 +01:00
|
|
|
|
|
|
|
(void) pthread_mutex_lock(&binddomain_mutex);
|
|
|
|
|
|
|
|
if (!already_bound)
|
|
|
|
{
|
|
|
|
const char *ldir;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No relocatable lookup here because the calling executable could
|
|
|
|
* be anywhere
|
|
|
|
*/
|
|
|
|
ldir = getenv("PGLOCALEDIR");
|
|
|
|
if (!ldir)
|
|
|
|
ldir = LOCALEDIR;
|
|
|
|
bindtextdomain(PG_TEXTDOMAIN("libpq"), ldir);
|
|
|
|
already_bound = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
(void) pthread_mutex_unlock(&binddomain_mutex);
|
|
|
|
|
2005-07-08 17:24:41 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
SetLastError(save_errno);
|
|
|
|
#else
|
2005-07-06 18:25:59 +02:00
|
|
|
errno = save_errno;
|
2005-07-08 17:24:41 +02:00
|
|
|
#endif
|
2001-07-15 15:45:04 +02:00
|
|
|
}
|
2014-09-12 16:12:11 +02:00
|
|
|
}
|
2001-07-15 15:45:04 +02:00
|
|
|
|
2014-09-12 16:12:11 +02:00
|
|
|
char *
|
|
|
|
libpq_gettext(const char *msgid)
|
|
|
|
{
|
|
|
|
libpq_binddomain();
|
2008-12-11 08:34:09 +01:00
|
|
|
return dgettext(PG_TEXTDOMAIN("libpq"), msgid);
|
2001-07-15 15:45:04 +02:00
|
|
|
}
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2014-09-12 16:12:11 +02:00
|
|
|
char *
|
|
|
|
libpq_ngettext(const char *msgid, const char *msgid_plural, unsigned long n)
|
|
|
|
{
|
|
|
|
libpq_binddomain();
|
|
|
|
return dngettext(PG_TEXTDOMAIN("libpq"), msgid, msgid_plural, n);
|
|
|
|
}
|
|
|
|
|
2001-07-15 15:45:04 +02:00
|
|
|
#endif /* ENABLE_NLS */
|
2022-11-15 11:50:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Append a formatted string to the given buffer, after translating it. A
|
|
|
|
* newline is automatically appended; the format should not end with a
|
|
|
|
* newline.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
libpq_append_error(PQExpBuffer errorMessage, const char *fmt,...)
|
|
|
|
{
|
|
|
|
int save_errno = errno;
|
|
|
|
bool done;
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
Assert(fmt[strlen(fmt) - 1] != '\n');
|
|
|
|
|
|
|
|
if (PQExpBufferBroken(errorMessage))
|
|
|
|
return; /* already failed */
|
|
|
|
|
|
|
|
/* Loop in case we have to retry after enlarging the buffer. */
|
|
|
|
do
|
|
|
|
{
|
|
|
|
errno = save_errno;
|
|
|
|
va_start(args, fmt);
|
|
|
|
done = appendPQExpBufferVA(errorMessage, libpq_gettext(fmt), args);
|
|
|
|
va_end(args);
|
|
|
|
} while (!done);
|
|
|
|
|
|
|
|
appendPQExpBufferChar(errorMessage, '\n');
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Append a formatted string to the error message buffer of the given
|
|
|
|
* connection, after translating it. A newline is automatically appended; the
|
|
|
|
* format should not end with a newline.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
libpq_append_conn_error(PGconn *conn, const char *fmt,...)
|
|
|
|
{
|
|
|
|
int save_errno = errno;
|
|
|
|
bool done;
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
Assert(fmt[strlen(fmt) - 1] != '\n');
|
|
|
|
|
|
|
|
if (PQExpBufferBroken(&conn->errorMessage))
|
|
|
|
return; /* already failed */
|
|
|
|
|
|
|
|
/* Loop in case we have to retry after enlarging the buffer. */
|
|
|
|
do
|
|
|
|
{
|
|
|
|
errno = save_errno;
|
|
|
|
va_start(args, fmt);
|
|
|
|
done = appendPQExpBufferVA(&conn->errorMessage, libpq_gettext(fmt), args);
|
|
|
|
va_end(args);
|
|
|
|
} while (!done);
|
|
|
|
|
|
|
|
appendPQExpBufferChar(&conn->errorMessage, '\n');
|
|
|
|
}
|