On 2018-12-16 07:03, Tom Lane wrote:
> Erik Rijkers <er@xs4all.nl> writes:
>> I have noticed that since ffa4cbd623, a foreign table that pulls data
>> from a PROGRAM (in this case an unzip call) will fail if there is a
>> LIMIT on the SELECT
>> (while succeeding without LIMIT). Below is an example.
>
> 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?
I admit it's suspicious. I am assuming I pull the latest, from
REL_11_STABLE, but I will have another hard look at my build stuff.
On the other hand, in that test.sh, have you tried enlarging the test
table? It works for me too with small enough values in that
generate_series.
> If not, there must be some platform-specific behavior involved.
> What are you testing on, exactly?
This is debian 9/Stretch:
/etc/os-release:
"Debian GNU/Linux 9 (stretch)"
uname -a
Linux gulo 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
GNU/Linux
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
stepping : 7
microcode : 0x25
cpu MHz : 2299.645
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp l
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf
bogomips : 6185.58
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
$ (PGSERVICE=dev11 psql -c "select version()")
PostgreSQL 11.1_REL_11_STABLE_20181216_0458_171c on
x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0
20170516, 64-bit
(1 row)
(note that '171c', tacked on via --with-extra-version)
What other info could be useful?