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-16T22:33:17Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

I wrote:
> I just had a thought about that: suppose we add a flag to CopyState
> to indicate whether we reached EOF while reading.  ...
> Then the logic in ClosePipeToProgram could be "if we did not reach
> EOF, then a SIGPIPE termination is unsurprising.  If we did reach
> EOF, then SIGPIPE is an error."  If the called program gets SIGPIPE
> for some reason other than us closing the pipe early, then we would
> see EOF next time we try to read, and correctly report that there's
> a problem.

Concretely, something like the attached.

I'm not quite sure whether the reached_eof test should be
"if (bytesread == 0)" or "if (bytesread < maxread)".  The former
seems more certain to indicate real EOF; are there other cases where
the fread might return a short read?  On the other hand, if we
support in-band EOF indicators (\. for instance) then we might
stop without having made an extra call to CopyGetData that would
see bytesread == 0.  On the third hand, if we do do that it's
not quite clear to me whether SIGPIPE is ignorable or 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.