Ensure consistent sort order of large objects in pg_dump.

The primary purpose of this commit is to ensure pg_upgrade tests yield
comparable dumps pre/post upgrade, which got broken by 12a53c732 /
578b229718, as the order in pg_largeobject_metadata is likely to
differ pre/post upgrade.

It also seems like a generally good idea to make sure such dumps are
comparable, outside of pg_upgrade tests.

LO metadata already was already dumped in an ordered manner as the
metadata is dumped in a well defined order via
sortDumpableObjectsByTypeName() and sortDumpableObjects(). But large
object data is currently not tracked via that mechanism.

As Tom points out it seems possible that at some point dumpBlobs() was
assumed to dump out objects in a well defined order, due to the use of
DISTINCT, which at that time only was done using sorting.

Per complaint from Andrew Dunstan and discussion with him and Tom
Lane.

Author: Andres Freund
Discussion: https://postgr.es/m/2735.1543333649@sss.pgh.pa.us

diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 6a0fcdd4c3cc0dc8c6841400c5d168e93a7f19e2..d583154fba052d9be22ff693f8e41cbe2644950d 100644 (file)
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -3328,9 +3328,13 @@ dumpBlobs(Archive *fout, void *arg)
     * the already-in-memory dumpable objects instead...
     */
    if (fout->remoteVersion >= 90000)
-       blobQry = "DECLARE bloboid CURSOR FOR SELECT oid FROM pg_largeobject_metadata";
+       blobQry =
+           "DECLARE bloboid CURSOR FOR "
+           "SELECT oid FROM pg_largeobject_metadata ORDER BY 1";
    else
-       blobQry = "DECLARE bloboid CURSOR FOR SELECT DISTINCT loid FROM pg_largeobject";
+       blobQry =
+           "DECLARE bloboid CURSOR FOR "
+           "SELECT DISTINCT loid FROM pg_largeobject ORDER BY 1";
 
    ExecuteSqlStatement(fout, blobQry);