From: Michael Paquier <michael@paquier.xyz>
To: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Is this a problem in GenericXLogFinish()?
Date: Tue, 9 Apr 2024 15:53:08 +0900
Message-ID: <ZhTl1KeyZNuOKP4S@paquier.xyz> (raw)
In-Reply-To: <OSBPR01MB25528A4CF6FF6E45B3DAFB0FF5032@OSBPR01MB2552.jpnprd01.prod.outlook.com>
References: <CAA4eK1LSCK1u_sRih7i8MOvp2VkrWD-YGESipAsDWNUrNKjo5w@mail.gmail.com>
<ZbyVVG_7eW3YD5-A@paquier.xyz>
<TYCPR01MB12077D8D2D4111BD6DAB21B58F5472@TYCPR01MB12077.jpnprd01.prod.outlook.com>
<CAA4eK1+Sf6eZ7+WwCv0HaKgpVQmoVtp3dYAoPYJFMxG8f+tbWA@mail.gmail.com>
<TYCPR01MB120779108BF1FC04A62A7E703F5472@TYCPR01MB12077.jpnprd01.prod.outlook.com>
<ZcCWQ9uOkZkX4gGx@paquier.xyz>
<CAA4eK1KiBbq=jVOJfTE2g=YYOODaWX9i-ix1Wrrufz9gK8F-0Q@mail.gmail.com>
<ZcNQfVqNCv-S813C@paquier.xyz>
<Zg99dfJ5t6k1wcB1@paquier.xyz>
<OSBPR01MB25528A4CF6FF6E45B3DAFB0FF5032@OSBPR01MB2552.jpnprd01.prod.outlook.com>
On Fri, Apr 05, 2024 at 06:22:58AM +0000, Hayato Kuroda (Fujitsu) wrote:
> Thanks for pointing out. Yes, we fixed a behavior by the commit aa5edbe37,
> but we missed the redo case. I made a fix patch based on the suggestion [1].
+ bool mod_buf = false;
Perhaps you could name that mod_wbuf, to be consistent with the WAL
insert path.
I'm slightly annoyed by the fact that there is no check on
is_prim_bucket_same_wrt for buffer 1 in the BLK_NEEDS_REDO case to
show the symmetry between the insert and replay paths. Shouldn't
there be at least an assert for that in the branch when there are no
tuples (imagine an else to cover xldata->ntups == 0)? I mean between
just before updating the hash page's opaque area when
is_prev_bucket_same_wrt.
I've been thinking about ways to make such cases detectable in an
automated fashion. The best choice would be
verifyBackupPageConsistency(), just after RestoreBlockImage() on the
copy of the block image stored in WAL before applying the page masking
which would mask the LSN. A problem, unfortunately, is that we would
need to transfer the knowledge of REGBUF_NO_CHANGE as a new BKPIMAGE_*
flag so we would be able to track if the block rebuilt from the record
has the *same* LSN as the copy used for the consistency check. So
this edge consistency case would come at a cost, I am afraid, and the
8 bits of bimg_info are precious :/
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael@paquier.xyz, kuroda.hayato@fujitsu.com, amit.kapila16@gmail.com, exclusion@gmail.com, robertmhaas@gmail.com, pgsql@j-davis.com, hlinnaka@iki.fi
Subject: Re: Is this a problem in GenericXLogFinish()?
In-Reply-To: <ZhTl1KeyZNuOKP4S@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox