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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, thomas(dot)munro(at)enterprisedb(dot)com, eric(dot)cyr(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT
Date: 2018-11-19 22:12:53
Message-ID: 30691.1542665573@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> I agree that it's better to keep the BeginCopyFrom API as-is. Also, I
> think your version would handle SIGPIPE in COPY FROM PROGRAM more
> properly than what I proposed. So, +1 from me.

Thanks for reviewing! I've pushed it now, though at the last minute
I reconsidered resetting SIGUSR2 as my previous patch did. The trouble
with resetting that is that it results in a small window where receipt
of SIGUSR2 would result in backend termination, which we surely don't
want. Now, it doesn't look to me like the postmaster will ever send
SIGUSR2 to ordinary backends, but it wouldn't be terribly surprising
if someone makes a change that relies on the expectation of SIGUSR2
being SIG_IGN'd by backends. I don't see any real upside to resetting
SIGUSR2 for the called program that would justify taking any risk
there. (Note that this concern doesn't apply to SIGPIPE since we
only expect that to be raised synchronously, ie during a write.)

As Kyotaro-san said upthread, it's odd that exec() provides no
way to reset all the handlers to SIG_DFL on the child side.
But since it doesn't, we're not really able to do much more than
this.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2018-11-20 08:33:21 Re: Tables created WITH OIDS cannot be dumped/restored properly
Previous Message Thomas Munro 2018-11-19 19:51:49 Re: Fail to create PK or index for large table in Windows

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-11-19 22:32:37 Re: Buildfarm failures for hash indexes: buffer leaks
Previous Message Andres Freund 2018-11-19 22:05:17 Re: Buildfarm failures for hash indexes: buffer leaks