11.05.2024 07:25, Thomas Munro wrote:
On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin <exclus...@gmail.com> wrote:
11.05.2024 06:26, Thomas Munro wrote:
Perhaps a no-image, no-change registered buffer should not be
including an image, even for XLR_CHECK_CONSISTENCY? It's actually
useless for consistency checking too I guess, this issue aside,
because it doesn't change anything so there is nothing to check.
Yes, I think something wrong is here. I've reduced the reproducer to:
Does it reproduce if you do this?
- include_image = needs_backup || (info &
XLR_CHECK_CONSISTENCY) != 0;
+ include_image = needs_backup ||
+ ((info & XLR_CHECK_CONSISTENCY) != 0 &&
+ (regbuf->flags & REGBUF_NO_CHANGE) == 0);
No, it doesn't (at least with the latter, more targeted reproducer).
Unfortunately the back branches don't have that new flag from 00d7fb5e
so, even if this is the right direction (not sure, I don't understand
this clean registered buffer trick) then ... but wait, why are there
are no failures like this in the back branches (yet at least)? Does
your reproducer work for 16? I wonder if something relevant changed
recently, like f56a9def. CC'ing Michael and Amit K for info.
Maybe it's hard to hit (autovacuum needs to process the index page in a
narrow time frame), but locally I could reproduce the issue even on
ac27c74de(~1 too) from 2018-09-06 (I tried several last commits touching
hash indexes, didn't dig deeper).
Best regards,
Alexander
