Horton

Re: Test instability when pg_dump orders by OID

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Kirill Reshke <reshkekirill@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-08-10T17:10:50Z
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

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Aug 10, 2025 at 12:37 PM Noah Misch <noah@leadboat.com> wrote:
>> Thanks.  Given the current state of freeze for tomorrow's release wrap, the
>> decision is less obvious than usual.  I'm seeing these options:
>> 
>> 1. Remove the new assertion in v13-v18.
>> 2. Push your proposed fix.
>> 3. Change nothing.  (This would be the choice if one is maximally concerned
>> about deviating from the freeze and unconcerned about --enable-cassert
>> builds of releases.)
>> 
>> I am inclined to make today's change be (1).

> Sounds right to me.

I agree.  The fact that this case escaped notice suggests that there
might be more.  We don't want to ship a version of pg_dump that will
assert if that happens.  Keep the assert in HEAD, for sure, but it's
uncomfortable having it in back branches.

As for the actual fix, push it after the freeze lifts.  The fact that
we didn't quite get there on making dump order stable isn't a
freeze-break-worthy bug.

			regards, tom lane