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-26 22:50:18 |
Message-ID: | 20181126225018.ieqxs7el2qyh2gm4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-11-26 22:51:06 | Re: [HACKERS] PATCH: multivariate histograms and MCV lists |
Previous Message | Thomas Munro | 2018-11-26 22:46:50 | Re: Refactoring the checkpointer's fsync request queue |