Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
От | Robert Haas |
---|---|
Тема | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) |
Дата | |
Msg-id | CA+TgmoYZM6Hg1HR==2U7rct=4eab1psNBiCXJE1x55LrvR=gkQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
|
Список | pgsql-hackers |
On Thu, Aug 26, 2021 at 11:48 AM Bruce Momjian <bruce@momjian.us> wrote: > I am find to add it if it is minor, but I want to see the calculus of > its value vs complexity, which I have not seen spelled out. I don't think it's going to be all that complicated, but we're going to have to wait until we have something closer to a final patch before we can really evaluate that. I am honestly a little puzzled about why you think complexity is such a big issue for this patch in particular. I feel we do probably several hundred things every release cycle that are more complicated than this, so it doesn't seem like this is particularly extraordinary or needs a lot of extra scrutiny. I do think there is some risk that there are messy cases we can't handle cleanly, but if that becomes an issue then I'll abandon the effort until a solution can be found. I'm not trying to relentlessly drive something through that is a bad idea on principle. I agree with all Stephen's comments, too. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: