RE: pg_upgrade's interaction with pg_resetwal seems confusing

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: pg_upgrade's interaction with pg_resetwal seems confusing
Дата
Msg-id TYAPR01MB5866859A2AD7B2A6CF0074BBF5D2A@TYAPR01MB5866.jpnprd01.prod.outlook.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  (vignesh C <vignesh21@gmail.com>)
Список pgsql-hackers
Dear hackers,

> >
> > > >  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.
> >
> 
> But OTOH, just updating the control file via pg_upgrade may not be
> sufficient because we should keep the shutdown checkpoint record also
> updated with that value. See how pg_resetwal achieves it via
> RewriteControlFile() and WriteEmptyXLOG(). So, considering both the
> approaches it seems better to go with a server-side function as Robert
> suggested.

Based on these discussion, I implemented a server-side approach. An attached patch
adds a upgrade function which sets ShmemVariableCache->nextOid. It is called at
the end of the upgrade. Comments and name of issue_warnings_and_set_wal_level()
is also updated because they become outdated.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Следующее
От: Erki Eessaar
Дата:
Сообщение: Re: PostgreSQL domains and NOT NULL constraint