Re: There doesn't seem to be any case where PQputCopyEnd() returns 0

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: There doesn't seem to be any case where PQputCopyEnd() returns 0
Date: 2021-02-05 14:01:03
Message-ID: 68fd9fef-d235-8231-33c7-72d40e9dcc3f@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/02/05 16:52, Kasahara Tatsuhito wrote:
> Hi,
>
> The following is written in the comments of PQputCopyEnd().
>
> (snip)
> * Returns 1 if successful, 0 if data could not be sent (only possible
> * in nonblock mode), or -1 if an error occurs.
> (snip)
>
> The PQputCopyEnd() section of the manual (libpq.sgml) describes the following.
>
> The result is 1 if the termination message was sent; or in
> nonblocking mode, this may only indicate that the termination
> message was successfully queued. (In nonblocking mode, to be
> certain that the data has been sent, you should next wait for
> write-ready and call <xref linkend="libpq-PQflush"/>, repeating until it
> returns zero.) Zero indicates that the function could not queue
> the termination message because of full buffers; this will only
> happen in nonblocking mode. (In this case, wait for
> write-ready and try the <xref linkend="libpq-PQputCopyEnd"/> call
> again.) If a hard error occurs, -1 is returned; you can use
> <xref linkend="libpq-PQerrorMessage"/> to retrieve details.
>
>
> These says that 0 may be returned if a non-blocking mode is used, but
> there doesn't seem to be any case where 0 is returned in the code of
> PQputCopyEnd().

I found the past discussion [1] about this issue.

[1]
https://www.postgresql.org/message-id/CA+Tgmobjj+0modbnmjy7ezeBFOBo9d2mAVcSPkzLx4LtZmc==g@mail.gmail.com

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-02-05 14:01:17 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message japin 2021-02-05 13:21:37 Re: Support ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION ... syntax