Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE)

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Greg Burd <greg(at)burd(dot)me>, pgsql-hackers(at)postgresql(dot)org, vignesh21(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, michael(at)paquier(dot)xyz, pgsql(at)j-davis(dot)com, exclusion(at)gmail(dot)com
Subject: Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE)
Date: 2026-11-11 03:03:00
Message-ID: CAGRkXqT_AiwcsWZg5hnR1L2oWO8UpQpkL0iAjoZR+bey=GOWaQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Greg,

> One point I'd like a reviewer to look at in 0001:
>
> redo now reads a block the record does not register.

Could that be a torn page?

> The page is not modified, so it needs no full-page image and no LSN
> update; the old code registered it with REGBUF_NO_IMAGE, so redo already
> worked from the on-disk copy.

I think if we have a torn bucket page and an XLOG_HASH_DELETE for one
of its overflow pages before the FPI, we may hit an issue?

We do not register an FPI for it in hashbucketcleanup().

if (!xlrec.is_primary_bucket_page)
{
uint8 flags = REGBUF_STANDARD | REGBUF_NO_IMAGE |
REGBUF_NO_CHANGE;

XLogRegisterBuffer(0, bucket_buf, flags);
}

XLogRegisterBuffer(1, buf, REGBUF_STANDARD);

Then hash_xlog_delete() reads it from disk in the else branch, and
that read fails.

if (xldata->is_primary_bucket_page)
action = XLogReadBufferForRedoExtended(record, 1, RBM_NORMAL,
true, &deletebuf);
else
{
(void) XLogReadBufferForRedoExtended(record, 0, RBM_NORMAL,
true, &bucketbuf);

action = XLogReadBufferForRedo(record, 1, &deletebuf);
}

I don't think this is caused by your patch. This looks like an
existing bug in master.

I am afraid that adding an FPI will not work either, because VACUUM
only holds a pin on the page and not an exclusive lock. But getting an
exclusive lock may hit the deadlock you mentioned. Maybe the right way
is to fix it on the replay side?

Thanks,
Shihao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Raja Sai pranav 2026-11-11 03:17:17 Re: Re: Assertion failure in WAL summarizer
Previous Message Xuneng Zhou 2026-11-11 02:53:49 Re: Set 1s WaitLatch timeout if standby limit has expired in ResolveRecoveryConflictWithBufferPin