pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: thomas.munro@enterprisedb.com
Cc: eric.cyr@gmail.com
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT
Date: Sat, 17 Nov 2018 11:14:49 -0500
Message-ID: <23489.1542471289@sss.pgh.pa.us> (raw)
In-Reply-To: <9660.1542409841@sss.pgh.pa.us>
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>
	<5BE966F4.1040702@lab.ntt.co.jp>
	<5BEA9E82.1080709@lab.ntt.co.jp>
	<30744.1542388851@sss.pgh.pa.us>
	<31355.1542389631@sss.pgh.pa.us>
	<7865.1542407597@sss.pgh.pa.us>
	<9660.1542409841@sss.pgh.pa.us>

I wrote:
> After still further thought, it seems like "if (bytesread == 0)"
> is the right way to proceed.  That protects us against incorrectly
> setting reached_eof if the pipe is being run in unbuffered or
> line-buffered mode.  (Which copy.c doesn't do, at the moment,
> but I'd just as soon this code didn't need to assume that.
> Also, I'm not 100% convinced that Windows or other platforms
> might not act that way.)  In the case where we terminate early
> because we saw an in-band EOF marker, we would also not set reached_eof,
> and again that seems like a good outcome: if we see SIGPIPE it
> must mean that the program kept sending data after the EOF marker,
> and that seems like a good thing to complain about.  (It's only
> guaranteed to fail if the program sends more than the current pipe
> buffer-ful, but I don't feel a need to add extra code to check for
> nonempty buffer contents as we exit.)

Oh, wait, that last bit is backwards: if we see an in-band EOF mark,
and as a consequence exit without having set reached_eof, then the
exit code will think that SIGPIPE is ignorable.  So transmitting
more data after an EOF mark will not be complained of, whether
it's within the same bufferload or not.

Still, I can't get very excited about that.  Potentially we could
improve it by having the places that recognize EOF marks set 
reached_eof, but I'm unconvinced that it's worth the trouble.
I'm thinking that it's better to err in the direction of reporting
SIGPIPE less often not more often, considering that up to now
we've never reported it at all and there've been so few complaints.

			regards, tom lane




view thread (28+ messages)  latest in thread

Message-ID: <23489.1542471289@sss.pgh.pa.us>
Permalink:  ../23489.1542471289@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/23489.1542471289@sss.pgh.pa.us

 · 

reply

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: tgl@sss.pgh.pa.us, fujita.etsuro@lab.ntt.co.jp, horiguchi.kyotaro@lab.ntt.co.jp, thomas.munro@enterprisedb.com, eric.cyr@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT
  In-Reply-To: <23489.1542471289@sss.pgh.pa.us>

* 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