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