Ensure consistent sort order of large objects in pg_dump.

anarazel · anarazel · commit 471a7af585b1 · 2018-11-27T12:16:55.000-08:00
The primary purpose of this commit is to ensure pg_upgrade tests yield comparable dumps pre/post upgrade, which got broken by 12a53c7 / 578b229, 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
@@ -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);
 
