Etsuro Fujita 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
(2018/11/17 8:10), Tom Lane wrote:
I wrote:
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
At Sat, 17 Nov 2018 11:14:49 -0500, Tom Lane wrote in
<23489.1542471...@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
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
I wrote:
> 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
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
I wrote:
> Are we sufficiently convinced that we must have the dont-allow-partial
> option to not fix this in the back branches? I'm not.
I just had a thought about that: suppose we add a flag to CopyState
to indicate whether we reached EOF while reading. This wouldn't be
hugely expensive, just
Etsuro Fujita writes:
> * I think it's better to ignore the SIGPIPE failure in
> ClosePipeToProgram if we were in a COPY FROM PROGRAM that was allowed to
> terminate early and keep the behavior as-is otherwise. If we ignore
> that failure unconditionally in that function, eg, COPY TO PROGRAM
(2018/11/12 20:41), Etsuro Fujita wrote:
(2018/11/12 18:52), Kyotaro HORIGUCHI wrote:
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
(2018/11/12 18:52), Kyotaro HORIGUCHI wrote:
At Fri, 09 Nov 2018 18:27:09 +0900, Etsuro Fujita wrote
in<5be552ed.4040...@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
At Fri, 09 Nov 2018 18:27:09 +0900, Etsuro Fujita
wrote in <5be552ed.4040...@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
At Fri, 9 Nov 2018 20:32:54 +1300, Thomas Munro
wrote in
> On Fri, Nov 9, 2018 at 6:39 PM Kyotaro HORIGUCHI
> wrote:
> > Mmm..I didn't get an error at hand on both CentOS7 and High Sierra.
> >
> > | $ perl -e 'for (my $i=0; $i< 100; $i++) { print "$i\n"; }' | head -5
> > ...
> > | 4
> > |
(2018/11/09 14:39), Kyotaro HORIGUCHI wrote:
At Thu, 08 Nov 2018 21:52:31 +0900, Etsuro Fujita wrote
in<5be4318f.4040...@lab.ntt.co.jp>
(2018/11/08 10:50), Thomas Munro wrote:
I take back what I said earlier about false positives from other
pipes. I think it's only traditional Unix programs
On Fri, Nov 9, 2018 at 6:39 PM Kyotaro HORIGUCHI
wrote:
> Mmm..I didn't get an error at hand on both CentOS7 and High Sierra.
>
> | $ perl -e 'for (my $i=0; $i< 100; $i++) { print "$i\n"; }' | head -5
> ...
> | 4
> | $ echo $?
> | 0
That's the exit code from head. You can see python or
At Thu, 08 Nov 2018 21:52:31 +0900, Etsuro Fujita
wrote in <5be4318f.4040...@lab.ntt.co.jp>
> (2018/11/08 10:50), Thomas Munro wrote:
> > I take back what I said earlier about false positives from other
> > pipes. I think it's only traditional Unix programs designed for use
> > in pipelines and
(2018/11/08 10:50), Thomas Munro wrote:
On Wed, Nov 7, 2018 at 11:03 PM Etsuro Fujita
wrote:
(2018/11/07 9:22), Kyotaro HORIGUCHI wrote:
At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro Fujita
wrote in<5be18409.2070...@lab.ntt.co.jp>
(2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
even if it
On Wed, Nov 7, 2018 at 11:03 PM Etsuro Fujita
wrote:
> (2018/11/07 9:22), Kyotaro HORIGUCHI wrote:
> > At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro
> > Fujita wrote
> > in<5be18409.2070...@lab.ntt.co.jp>
> >> (2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
> >>> even if it comes from another pipe,
(2018/11/07 9:22), Kyotaro HORIGUCHI wrote:
At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro Fujita wrote
in<5be18409.2070...@lab.ntt.co.jp>
(2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro
Fujita wrote
in<5bdc4ba0.7050...@lab.ntt.co.jp>
(2018/10/29 15:58),
(2018/11/06 19:50), Thomas Munro wrote:
On Wed, Oct 24, 2018 at 1:21 AM Tom Lane wrote:
I wrote:
=?utf-8?q?PG_Bug_reporting_form?= writes:
SELECT * FROM test_file_fdw_program_limit LIMIT 0;
/*
[38000] ERROR: program "echo "test"" failed Detail: child process exited
with exit code 1
*/
At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro Fujita
wrote in <5be18409.2070...@lab.ntt.co.jp>
> (2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
> > At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro
> > Fujita wrote
> > in<5bdc4ba0.7050...@lab.ntt.co.jp>
> >> (2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
>
(2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro Fujita wrote
in<5bdc4ba0.7050...@lab.ntt.co.jp>
(2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
At Tue, 23 Oct 2018 13:21:31 +0100, Tom Lane wrote
in<18397.1540297...@sss.pgh.pa.us>
It's just a POC because
On Wed, Oct 24, 2018 at 1:21 AM Tom Lane wrote:
> I wrote:
> > =?utf-8?q?PG_Bug_reporting_form?= writes:
> >> SELECT * FROM test_file_fdw_program_limit LIMIT 0;
> >> /*
> >> [38000] ERROR: program "echo "test"" failed Detail: child process exited
> >> with exit code 1
> >> */
>
> > Yeah, I can
At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro Fujita
wrote in <5bdc4ba0.7050...@lab.ntt.co.jp>
> (2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
> > At Tue, 23 Oct 2018 13:21:31 +0100, Tom Lane wrote
> > in<18397.1540297...@sss.pgh.pa.us>
> >> After a bit of thought, the problem here is blindingly
(2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
At Tue, 23 Oct 2018 13:21:31 +0100, Tom Lane wrote
in<18397.1540297...@sss.pgh.pa.us>
After a bit of thought, the problem here is blindingly obvious:
we generally run the backend with SIGPIPE handing set to SIG_IGN,
and evidently popen() allows the
Hello.
At Tue, 23 Oct 2018 13:21:31 +0100, Tom Lane wrote in
<18397.1540297...@sss.pgh.pa.us>
> I wrote:
> > =?utf-8?q?PG_Bug_reporting_form?= writes:
> >> SELECT * FROM test_file_fdw_program_limit LIMIT 0;
> >> /*
> >> [38000] ERROR: program "echo "test"" failed Detail: child process exited
>
I wrote:
> =?utf-8?q?PG_Bug_reporting_form?= writes:
>> SELECT * FROM test_file_fdw_program_limit LIMIT 0;
>> /*
>> [38000] ERROR: program "echo "test"" failed Detail: child process exited
>> with exit code 1
>> */
> Yeah, I can reproduce this on macOS as well as Linux. Capturing stderr
> shows
26 matches
Mail list logo
