Re: [RFC] Removing "magic" oids
От | Andrew Dunstan |
---|---|
Тема | Re: [RFC] Removing "magic" oids |
Дата | |
Msg-id | 37786ace-8622-e4ba-43b5-50496f88b68d@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [RFC] Removing "magic" oids (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [RFC] Removing "magic" oids
|
Список | pgsql-hackers |
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. > > >> 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. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: