Horton

Re: Test instability when pg_dump orders by OID

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kirill Reshke <reshkekirill@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2025-08-25T21:15:55Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Rewrite previous commit's test for TestUpgradeXversion compatibility.

  2. Sort DO_DEFAULT_ACL dump objects independent of OIDs.

  3. Remove, from stable branches, the new assertion of no pg_dump OID sort.

  4. Sort dump objects independent of OIDs, for the 7 holdout object types.

  5. pg_dump: provide a stable sort order for rules.

  6. pg_dump: include comments on not-null constraints on domains, too

  7. Verify roundtrip dump/restore of regression database

  8. In pg_dump, use simplehash.h to look up dumpable objects by OID.

  9. Tweak pg_dumpall to add GRANT CONNECT ON DATABASE ... TO PUBLIC when dumping

  10. Restructure operator classes to allow improved handling of cross-data-type

  11. First phase of project to use fixed OIDs for all system catalogs and

  12. Tweak pg_dump to say GRANT ALL when appropriate, rather than enumerating

Hi,

On 2025-08-24 09:08:16 -0700, Noah Misch wrote:
> On Sun, Aug 24, 2025 at 11:50:01AM -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > I wonder if it's worth adding support to CI to perform the cross-version
> > > upgrade test. It'd be pretty easy to install all pgdg apt postgres packages to
> > > the debian image, which then could be used as the source version...
> 
> I think catching this particular case would take more than that.  It entails
> running the latest v16 src/test/regress suite, capturing the dump of that into
> $animal_root/upgrade.$animal/REL_16_STABLE/*.sql, and seeing the upgrade
> failure of that dump having the latest v16 regression objects.  I don't know
> how to get there without a v16 source tree.

Ah, ok, that does make it less worthwhile to go after.



> > I feel that that's the wrong tradeoff.  CI should be expected to be
> > fairly cheap, not to catch everything the buildfarm could catch.

I think it's also about removing painful manual testing - and imo manually
running cross-version pg_upgrade tests is really rather painful.


> It can always be non-default, like the mingw test.

Indeed.  We now have the infrastructure to enable such tests for cfbot while
not running by default in user's repositories (which will commonly be more
compute constrained).

Greetings,

Andres Freund