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

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>

From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: thomas.munro@enterprisedb.com
Cc: fujita.etsuro@lab.ntt.co.jp, tgl@sss.pgh.pa.us, eric.cyr@gmail.com, pgsql-bugs@lists.postgresql.org, pgsql-hackers@lists.postgresql.org
Date: 2018-11-12T09:23:51Z
Lists: pgsql-bugs, pgsql-hackers
At Fri, 9 Nov 2018 20:32:54 +1300, Thomas Munro <thomas.munro@enterprisedb.com> wrote in <CAEepm=21wvBaKY2cbN62xn8JoPygLLhTawK2TkBac8Suw68YBw@mail.gmail.com>
> On Fri, Nov 9, 2018 at 6:39 PM Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > Mmm..I didn't get an error at hand on both CentOS7 and High Sierra.
> >
> > | $ perl -e 'for (my $i=0; $i< 1000000; $i++) { print "$i\n"; }' | head -5
> > ...
> > | 4
> > | $ echo $?
> > | 0
> 
> That's the exit code from head.  You can see python or perl's exit
> code by adding strace in front (on Linux):

Sorry. My stupid. I understand it as head ignores not only
SIGPIPE but SIGSEV and any error exit status of the calling
program. I tried head with a program ends with SEGV and saw that
head ignores it.

$ ./t
line 1
Segmentation fault (core dumped)

$ ./t | head -5  # SEGV before head closes the pipe
line 1
$

This is more tolerant than what I proposed before. (I think it is
too-much tolerant for us).

> > create foreign table ft5 (a text) server svf1 options (program 'ruby -e "for i in 1..1000 do puts i; end"');
> > select * from ft5 limit 5;
> >  a
> > ---
> >  1
> > ...
> >  5
> > (5 rows)
> > (no error)
> 
> 1000 is not enough... due to buffering, it works.  Try 1000000:

Ah. Understood. Thanks. (Ruby's flush donesn't work for pipes..)

> postgres=# create foreign table ft5 (a text) server svf1 options
> (program 'ruby -e "for i in 1..1000000 do puts i; end"');
> CREATE FOREIGN TABLE
> postgres=# select * from ft5 limit 5;
> ERROR:  program "ruby -e "for i in 1..1000000 do puts i; end"" failed
> DETAIL:  child process exited with exit code 1

I saw the same failure. Ruby handles SIGPIPE and converts it to
exit(1). It cannot be handled by just ignoring SIGPIPE.

Ruby seems to be a friend of my second patch:p

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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.