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-16 22:33:17
Message-ID: 7865.1542407597@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

Attachment Content-Type Size
sigpipe-might-not-be-an-error-3.patch text/x-diff 6.5 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-11-16 23:10:41 Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT
Previous Message Melanie Plageman 2018-11-16 18:31:47 Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-11-16 22:36:11 Re: [HACKERS] pgbench - allow to store select results into variables
Previous Message Alvaro Herrera 2018-11-16 22:13:13 Re: [HACKERS] pgbench - allow to store select results into variables