Re: Possible corruption by CreateRestartPoint at promotion

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Possible corruption by CreateRestartPoint at promotion
Дата
Msg-id YnT/Y2sEYj7pyOdc@paquier.xyz
обсуждение исходный текст
Ответ на Re: Possible corruption by CreateRestartPoint at promotion  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Possible corruption by CreateRestartPoint at promotion  (Michael Paquier <michael@paquier.xyz>)
Re: Possible corruption by CreateRestartPoint at promotion  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Thu, Apr 28, 2022 at 03:49:42PM +0900, Michael Paquier wrote:
> I am not sure what you mean here.  FWIW, I am translating the
> suggestion of Nathan to split the existing check in
> CreateRestartPoint() that we are discussing here into two if blocks,
> instead of just one:
> - Move the update of checkPoint and checkPointCopy into its own if
> block, controlled only by the check on
> (ControlFile->checkPointCopy.redo < lastCheckPoint.redo)
> - Keep the code updating minRecoveryPoint and minRecoveryPointTLI
> mostly as-is, but just do the update when the control file state is
> DB_IN_ARCHIVE_RECOVERY.  Of course we need to keep the check on
> (minRecoveryPoint < lastCheckPointEndPtr).

And I have spent a bit of this stuff to finish with the attached.  It
will be a plus to get that done on HEAD for beta1, so I'll try to deal
with it on Monday.  I am still a bit stressed about the back branches
as concurrent checkpoints are possible via CreateCheckPoint() from the
startup process (not the case of HEAD), but the stable branches will
have a new point release very soon so let's revisit this choice there
later.  v6 attached includes a TAP test, but I don't intend to include
it as it is expensive.
--
Michael

Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: strange slow query - lost lot of time somewhere
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Fix typo in code comment - origin.c