From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | PQputCopyEnd doesn't adhere to its API contract |
Date: | 2014-05-08 15:10:29 |
Message-ID: | CA+Tgmobjj+0modbnmjy7ezeBFOBo9d2mAVcSPkzLx4LtZmc==g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
According to the documentation for PQputCopyEnd:
> The result is 1 if the termination data was sent, zero if it was not sent because the attempt would block (this case is only possible if the connection is in
> nonblocking mode), or -1 if an error occurred. (Use PQerrorMessage to retrieve details if the return value is -1. If the value is zero, wait for write-ready and try again.)
However, pqPutCopyEnd contains no return statement that can ever
possibly return 0. I think the problem is approximately here:
/* Try to flush data */
if (pqFlush(conn) < 0)
return -1;
pqFlush() returns 0 if no data is waiting to be sent, or otherwise the
return value of pqSendSome(). pqSendSome() returns -1 if an error
occurs, 0 if all data is sent, or 1 if some data was sent but the
socket is non-blocking and the caller must try again later. It seems
to me that when pqSendSome() returns 1, pqPutCopyEnd ought to return 0
in order to meet its API contract - and then the client, presumably,
should repeatedly wait for the socket to become write-ready and then
try PQflush() until PQflush() returns non-zero.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-05-08 15:19:02 | Re: popen and pclose redefinitions causing many warning in Windows build |
Previous Message | Andres Freund | 2014-05-08 14:59:01 | Re: postgresql.auto.conf read from wrong directory |