Re: pg_amcheck contrib application

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Thomas Munro <thomas.munro@gmail.com>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>, Amul Sul <sulamul@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-13T07:36:39Z
Lists: pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Sat, Mar 13, 2021 at 01:36:11AM -0500, Tom Lane wrote:
>> 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.

Yeah.  prairiedog and gaur are both frankenstein systems: some of the
software components are years newer than the underlying OS.  So I don't
mind changing them further; in the end they're both in the buildfarm
for reasons of hardware diversity, not because they represent platforms
anyone would run production PG on.  On the other hand, those AIX animals
represent systems that are still considered production grade (no?), so
we have to be willing to adapt to them not vice versa.

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

I'm only concerned about whether the all-zero value causes any
significant degradation in test quality.  Probably Peter G. would
have the most informed opinion about that.

			regards, tom lane



Commits

  1. amcheck: Improve some confusing reports about TOAST problems.

  2. amcheck: Reword some messages and fix an alignment problem.

  3. amcheck: fix multiple problems with TOAST pointer validation

  4. amcheck: Remove duplicate XID/MXID bounds checks.

  5. amcheck: Fix verify_heapam's tuple visibility checking rules.

  6. nbtree VACUUM: Cope with buggy opclasses.

  7. Improve pg_amcheck's TAP test 003_check.pl.

  8. Fix a confusing amcheck corruption message.

  9. Doc: add note about how to run the pg_amcheck regression tests.

  10. In pg_amcheck tests, don't depend on perl's Q/q pack code.

  11. pg_amcheck: Keep trying to fix the tests.

  12. pg_amcheck: Try to fix still more test failures.

  13. Try to avoid apparent platform-dependency in IPC::Run

  14. Fix portability issues in pg_amcheck's 004_verify_heapam.pl.

  15. Try to fix compiler warnings.

  16. Add pg_amcheck, a CLI for contrib/amcheck.

  17. Refactor and generalize the ParallelSlot machinery.

  18. Remove old-style VACUUM FULL (which was known for a little while as