Re: Possible corruption by CreateRestartPoint at promotion

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: nathandbossart(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, masao(dot)fujii(at)oss(dot)nttdata(dot)com
Subject: Re: Possible corruption by CreateRestartPoint at promotion
Date: 2022-05-06 10:58:43
Message-ID: YnT/Y2sEYj7pyOdc@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
v6-0001-Correctly-update-control-file-at-promotion.patch text/x-diff 7.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-05-06 11:02:36 Re: Fix typo in code comment - origin.c
Previous Message Pavel Stehule 2022-05-06 10:31:23 Re: strange slow query - lost lot of time somewhere