PQputCopyEnd doesn't adhere to its API contract

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

Responses

Browse pgsql-hackers by date

  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