| 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
| 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 |