Re: pg_amcheck contrib application

On Sat, Mar 13, 2021 at 01:36:11AM -0500, Tom Lane wrote:
> Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> > On Mar 12, 2021, at 10:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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 don't mind updating the perl installations on prairiedog and gaur,
> but Noah might have some difficulty with his AIX flotilla, as I believe
> he's not sysadmin there.

The AIX animals have Perl v5.28.1. hoverfly, in particular, got a big update
package less than a month ago. Hence, I doubt it's a question of applying
routine updates. The puzzle would be to either (a) compile a 32-bit Perl that
handles unpack('q') or (b) try a PostgreSQL configuration like "./configure
... PROVE='perl64 /usr/bin/prove --'" to run the TAP suites under perl64.
(For hoverfly, it's enough to run "prove" under $PERL. mandrill, however,
needs a 32-bit $PERL for plperl, regardless of what it needs for "prove".)
Future AIX packagers would face doing the same.

With v5-0001-pg_amcheck-continuing-to-fix-portability-problems.patch being so
self-contained, something like it is the way to go.