From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: thomas.munro@enterprisedb.com
Cc: tgl@sss.pgh.pa.us
Cc: eric.cyr@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT
Date: Mon, 12 Nov 2018 20:41:40 +0900
Message-ID: <5BE966F4.1040702@lab.ntt.co.jp> (raw)
In-Reply-To: <20181112.185214.76711162.horiguchi.kyotaro@lab.ntt.co.jp>
References: <5BE4318F.4040002@lab.ntt.co.jp>
<20181109.143931.243136889.horiguchi.kyotaro@lab.ntt.co.jp>
<5BE552ED.4040304@lab.ntt.co.jp>
<20181112.185214.76711162.horiguchi.kyotaro@lab.ntt.co.jp>
(2018/11/12 18:52), Kyotaro HORIGUCHI wrote:
> At Fri, 09 Nov 2018 18:27:09 +0900, Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp> wrote in<5BE552ED.4040304@lab.ntt.co.jp>
>>> Ok, I can live with that with no problem.
>>
>> OK
> ...
>>> I think Thomas just saying that reading more lines can develop
>>> problems. According to the current discussion, we should error
>>> out if we had SEGV when limit 1.
>>
>> Ah, I misread that. Sorry for the noise.
>
> Being said that, the ruby case may suggest that we should be more
> tolerant for the crash-after-limit case.
The Ruby case would be sad, but I'm not sure we can handle such a case
safely in general, because core and file_fdw don't have enough knowledge
about whether a non-zero exit code returned from pclose is OK or not,
which would actually depend on the called program. One approach for
that would be to add an option to file_fdw for the called program to
tell it to ignore those exit codes, which would be somewhat similar to
what Thomas proposed [1].
>>> In my understanding processes not connected to a
>>> terminal(tty/pts) cannot receive TTIN/TTOU (unless someone sent
>>> it artifically). Since child processes are detached by setsid()
>>> (on Linux), programs called in that way also won't have a
>>> controlling terminal at the start time and I suppose they have no
>>> means to connect to one since they are no longer on the same
>>> session with postmaster.
>>
>> For TTIN and TTOU, we would first need to make clear the reason for
>> the inconsistency Thomas pointed out. I'm wondering if we should
>> leave the TTIN/TTOU stuff for future work.
>
> Inconsistency?
By "the inconsistency" I mean his words:
Why do bgwriter.c, startup.c, ... set SIGTTIN and SIGTTOU back to
SIG_DFL, but not regular backends?
> I read the Thomas's messages as "TTIO/TTOU are not
> needed to our busines and we don't have a reason to restore them
> before calling external programs other than just plaster
> seemingly consistency." And I agree to the analysis and I agree
> to you on the point that it doens't need consideration just now.
OK
> If the consistency means the different behaviors between perl and
> ruby, (as written in another message,) I'm inclined to vote for
> having a bit more tolerance for error of external programs as my
> second patch.
Maybe my explanation was not enough, but I don't mean that.
Thanks!
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/CAEepm%3D0fBPiRkSiJ3v4ynm%2BaP-A-dhuHjTFBAxwo59EkE2-E5Q%40mail...
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: fujita.etsuro@lab.ntt.co.jp, horiguchi.kyotaro@lab.ntt.co.jp, thomas.munro@enterprisedb.com, tgl@sss.pgh.pa.us, eric.cyr@gmail.com, pgsql-bugs@lists.postgresql.org, pgsql-hackers@lists.postgresql.org
Subject: Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT
In-Reply-To: <5BE966F4.1040702@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox