> On Mar 12, 2021, at 10:28 PM, Mark Dilger <mark.dil...@enterprisedb.com> > wrote: > > > >> On Mar 12, 2021, at 10:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Mark Dilger <mark.dil...@enterprisedb.com> writes: >>> On Mar 12, 2021, at 10:16 PM, Noah Misch <n...@leadboat.com> wrote: >>>> hoverfly does configure with PERL=perl64. /usr/bin/prove is from the >>>> 32-bit >>>> Perl, so I suspect the TAP suites get 32-bit Perl that way. (There's no >>>> "prove64".) >> >> Oh, that's annoying. >> >>>> This test should unpack the field as two 32-bit values, not a >>>> 64-bit value, to avoid requiring more from the Perl installation. >> >>> I will post a modified test in a bit that avoids using Q/q. >> >> Coping with both endiannesses might be painful. > > Not too bad if the bigint value is zero, as both the low and high 32bits will > be zero, regardless of endianness. The question is whether that gives up too > much in terms of what the test is trying to do. I'm not sure that it does, > but if you'd rather solve this by upgrading perl, that's ok by me.
I'm not advocating that this be the solution, but if we don't fix up the perl end of it, then this test change might be used instead.
v5-0001-pg_amcheck-continuing-to-fix-portability-problems.patch
Description: Binary data
— Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
