Re: pg_upgrade's interaction with pg_resetwal seems confusing
От | Dilip Kumar |
---|---|
Тема | Re: pg_upgrade's interaction with pg_resetwal seems confusing |
Дата | |
Msg-id | CAFiTN-tMdyNUDKet8WMP32e+FtuDf0aRbYUJ3zVR5fs1chfqGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade's interaction with pg_resetwal seems confusing (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: pg_upgrade's interaction with pg_resetwal seems confusing
|
Список | pgsql-hackers |
On Fri, Oct 13, 2023 at 11:07 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > But is this a problem? basically, we will set the > > ShmemVariableCache->nextOid counter to the value that we want in the > > IsBinaryUpgrade-specific function. And then the shutdown checkpoint > > will flush that value to the control file and that is what we want no? > > > > I think that can work. Basically, we need to do something like what > SetNextObjectId() does and then let the shutdown checkpoint update the > actual value in the control file. Right. > > I mean instead of resetwal directly modifying the control file we > > will modify that value in the server using the binary_upgrade function > > and then have that value flush to the disk by shutdown checkpoint. > > > > True, the alternative to consider is to let pg_upgrade update the > control file by itself with the required value of OID. The point I am > slightly worried about doing via server-side function is that some > online and or shutdown checkpoint can update other values in the > control file as well whereas if we do via pg_upgrade, we can have > better control over just updating the OID. Yeah, thats a valid point. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: