From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] Removing "magic" oids |
Date: | 2018-11-22 21:14:52 |
Message-ID: | 20181122211452.3bffatkaknmrvkdq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-11-22 22:03:14 | Re: Hitting CheckRelationLockedByMe() ASSERT with force_generic_plan |
Previous Message | Andrew Dunstan | 2018-11-22 20:37:23 | Re: pg_upgrade supported versions policy |