From: | Erik Rijkers <er(at)xs4all(dot)nl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: select limit error in file_fdw |
Date: | 2018-12-16 16:45:58 |
Message-ID: | 73daf46bd199f9d19a078bb052f14d56@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-12-16 16:52, Tom Lane wrote:
> Erik Rijkers <er(at)xs4all(dot)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
curious...
Adding that ' | cat' tail makes all 3 instances (that I have tried)
fail:
11.1 as released,
REL_11_STABLE, and
instance from d56e0fde
/bin/sh seems to be dash, here.
bash version is:
$ /bin/bash --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2018-12-16 16:50:15 | reducing the footprint of ScanKeyword (was Re: Large writable variables) |
Previous Message | Tom Lane | 2018-12-16 16:16:20 | Re: Alternative to \copy in psql modelled after \g |