Hi, On 2018-11-22 17:12:31 -0500, Andrew Dunstan wrote: > > On 11/22/18 4:14 PM, Andres Freund wrote: > > Hi, > > > > On 2018-11-21 23:32:07 -0500, Andrew Dunstan wrote: > > > On 11/21/18 7:14 PM, Andres Freund wrote: > > > > Could you check whether you > > > > still encounter the issue after applying the attached fix? > > > > > > > > > > This has largely fixed the problem, so I think this should be applied. > > Cool, will do so tomorrow or such. Thanks for testing.
Sorry, the long weekend delayed this. Pushed now. > > > With some adjustments to the tests to remove problematic cases (e.g. > > > postgres_fdw's ft_pg_type) the tests pass. The exception is > > > HEAD->HEAD. The change is that the LOs are not dumped in the same > > > order pre and post upgrade. I can change the tests to allow for a > > > greater fuzz factor - generally when the source and target are the > > > same we don't allow any fuzz. Or if we care we could do a better job > > > of dumping LOs in a consistent order. > > So you'd want to dump large objects in oid order or such? Probably > > comparatively not a huge overhead, but also not nothing? We don't really > > force ordering in other places in pg_dump afaik. > > > > Well, all other data is dumped in a consistent order, and the tests rely on > this. If we don't care about that for LOs I can accommodate it. I don't have > a terribly strong opinion about the desirability of making LOs keep the same > behaviour. I don't think it's true that other comparable metadata is dumped in a really consistent order. What changes is the order of data in a system catalog (pg_largeobject_metadata), and we don't enforce that the order stays the same in e.g. pg_class either. I guess we could add a not-actually-needed sort to getBlobs(), with a comment saying that we only need that for better comparability and note that it's less needed for other types of objects due to the dependency ordering that pg_dump does for most object types. Greetings, Andres Freund
