Re: pg_dump sort priority mismatch for large objects
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Nitin Motiani <nitinmotiani@google.com>,
Hannu Krosing <hannuk@google.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-10T17:38:40Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes: > On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote: >> I looked through the history of this to see how this happened and if it >> could be an existing issue. Prior to a45c78e3284b, dumpLO used to put large >> objects in SECTION_PRE_DATA. That commit changed dumpLO and also changed >> addBoundaryDependencies to move DO_LARGE_OBJECT from pre-data to data >> section. Seems like since then this has been inconsistent with >> pg_dump_sort.c. I think the change in pg_dump_sort.c should be backported >> to PG17 & 18 independent of the state of the larger patch. > +1, if for no other reason than we'll need it to be below PRIO_TABLE_DATA > for the speed-up-pg_upgrade-with-many-LOs patch [0]. Does anyone see any > problems with applying something like the following down to v17? That's clearly an oversight in a45c78e3284b. I agree that fixing pg_dump_sort.c to match shouldn't create any functional difficulties. It might make the topological sort step marginally faster by reducing the number of ordering violations that have to be fixed. regards, tom lane
Commits
-
pg_dump: Fix object-type sort priority for large objects.
- fb6c860bbd1f 19 (unreleased) landed
- e43fae199e50 17.6 landed
- 36026b0fe3ab 18.0 landed