Horton

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, thomas.munro@enterprisedb.com, eric.cyr@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2018-11-16T17:20:51Z
Lists: pgsql-bugs, pgsql-hackers 
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> * I think it's better to ignore the SIGPIPE failure in 
> ClosePipeToProgram if we were in a COPY FROM PROGRAM that was allowed to 
> terminate early and keep the behavior as-is otherwise.  If we ignore 
> that failure unconditionally in that function, eg, COPY TO PROGRAM would 
> fail to get a (better) error message in CopySendEndOfRow or EndCopy when 
> the invoked program was terminated on SIGPIPE, as discussed before [1]. 
>   And to do so, I added a new argument to BeginCopyFrom to specify 
> whether COPY FROM PROGRAM can terminate early or not.

If we do that, it makes this not back-patchable, I fear --- the fact
that file_fdw is calling BeginCopyFrom seems like sufficient evidence
that there might be third-party callers who would object to an API
break in minor releases.  That seems unfortunate for a bug fix.

Are we sufficiently convinced that we must have the dont-allow-partial
option to not fix this in the back branches?  I'm not.

			regards, tom lane

Commits

  1. Handle EPIPE more sanely when we close a pipe reading from a program.

  2. Avoid defining SIGTTIN/SIGTTOU on Windows.

  3. Leave SIGTTIN/SIGTTOU signal handling alone in postmaster child processes.

  4. Remove some unnecessary pqsignal() calls to shave a few cycles off

  5. Fix handling of SIGCHLD, per recent pghackers discussion: on some

  6. The new files for statistical system views.

  7. Remove fork()/exec() and only do fork(). Small cleanups.