From 471a7af585b123a8c00416eabbec927f6701583d Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Tue, 27 Nov 2018 12:16:55 -0800 Subject: [PATCH] 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 --- src/bin/pg_dump/pg_dump.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index 6a0fcdd4c3c..d583154fba0 100644 --- 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); -- 2.30.2