Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> In any case, I think we will probably need to bite the bullet and have
> pg_dump render LOs in OID order.
+1. Looking at the relevant code:
/*
* Currently, we re-fetch all BLOB OIDs using a cursor. Consider scanning
* the already-in-memory dumpable objects instead...
*/
if (fout->remoteVersion >= 90000)
blobQry = "DECLARE bloboid CURSOR FOR SELECT oid FROM pg_largeobject_metadata";
else
blobQry = "DECLARE bloboid CURSOR FOR SELECT DISTINCT loid FROM pg_largeobject";
I suspect that the original expectation was that SELECT DISTINCT would
deliver the blob OIDs in sorted order, and nobody noticed when hash-based
DISTINCT broke that, and then the pg_largeobject_metadata patch figured
that it didn't need to preserve a guarantee that wasn't there.
We have taken pains in the past to ensure consistent dump ordering, and
it seems to me the lack of that here is just an oversight. It's kinda
surprising that it hasn't bit us before.
> Not sure if that needs to be always on,
> or an option.
We have no existing option that says "you can skip ordering my dump
consistently". I see no need for one here.
The easy fix is to add "ORDER BY 1" to both of the above queries.
If anyone is concerned about the performance of that, they could
go try to do what the comment suggests, but I'm not personally
excited about that.
regards, tom lane