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
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 |
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 |