On 11/26/18 5:50 PM, Andres Freund wrote:
>
>>>> 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.
>
As of now, I have simnply got around the issue in the buildfarm module
by allowing up to 50 lines of fuzz in the pre-upgrade and post-upgrade
diffs when the source and destination branch are the same.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services