On Thu, Jan 09, 2020 at 12:45:41AM -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > Even so, a web search for "extend_brk" led to the answer. By default, > > 32-bit > > AIX binaries get only 256M of RAM for stack and sbrk. The new regression > > test > > used more than that, hence this crash. > > Hm, so > > (1) Why did we get a crash and not some more-decipherable out-of-resources > error? Can we improve that experience?
By default, 32-bit AIX binaries have maxdata:0x00000000. Specifying maxdata:0x10000000 provides the same 256M of RAM, yet it magically changes the SIGSEGV to ENOMEM: $ OBJECT_MODE=32 gcc maxdata.c && ./a.out Segmentation fault $ OBJECT_MODE=32 gcc -Wl,-bmaxdata:0x00000000 maxdata.c && ./a.out Segmentation fault $ OBJECT_MODE=32 gcc -Wl,-bmaxdata:0x10000000 maxdata.c && ./a.out done at 255 MiB: Not enough space We could add -Wl,-bmaxdata:0x10000000 (or a higher value) to LDFLAGS when building for 32-bit AIX. > (2) Should we be dialing back the resource consumption of this test? > Even on machines where it doesn't fail outright, I'd imagine that it's > costing a lot of buildfarm cycles. Is it actually worth that? The test's resource usage, being quite low, should not be a factor in the test's fate. On my usual development machine, the entire 006_logical_decoding.pl file takes just 3s and ~250 MiB of RAM.
