Erik Rijkers <e...@xs4all.nl> writes:
> On 2018-12-16 07:03, Tom Lane wrote:
>> Um ... this example works for me, in both HEAD and v11 branch tip.
>> Moreover, the behavior you describe is exactly what ffa4cbd623 was
>> intended to fix. Is there any chance that you got 11.1 and v11
>> branch tip mixed up?
> [ nope ]
> On the other hand, in that test.sh, have you tried enlarging the test
> table?
Yeah, I tried sizes ranging up to 1m tuples without success.
However, something else occurred to me this morning, and a bit
later I can reproduce the problem! I did it by changing the
table's definition to use a shell pipeline:
program 'unzip -p \"/tmp/t.zip\" \"tmp/t.txt\" | cat'
ERROR: program "unzip -p "/tmp/t.zip" "tmp/t.txt" | cat" failed
DETAIL: child process exited with exit code 141
What is happening for me, I think, is that if the PROGRAM is
just "unzip" then the shell exec's it directly, and so the
SIGPIPE result is reported directly to the PG backend. But
if the PROGRAM is too complicated to handle that way, then
unzip and cat are children of a shell process, and one or both
of them get SIGPIPE, and the shell reports that as exit status
128 + SIGPIPE. So we need to consider that result as indicating
a sigpipe failure, too.
It remains unclear why you had an intervening shell process when
I didn't, but perhaps that can be chalked up to use of a different
shell?
regards, tom lane
