Horton

Re: Test instability when pg_dump orders by OID

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
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-26T00:57:24Z
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

On Mon, Aug 25, 2025 at 05:15:55PM -0400, Andres Freund wrote:
> 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.

I make the buildfarm client drive it.  That was painful to set up the first
time[1], but the per-run manual pain isn't bad.  A run of all supported
branches takes hours of wall time, though.  There are some optimization
opportunities, but it hasn't come up often enough to make those compelling for
me to implement.


[1] For example, there's no one OpenSSL version compatible with all of v9.2 -
v19.  Disabling SSL doesn't solve that: some versions then disable pgcrypto,
and the upgrade test fails for pgcrypto being absent on one side of the
upgrade.  I settled on SSL only for the versions where pgcrypto requires it.
Version-dependent LD_LIBRARY_PATH etc. likely would have been an alternative.