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

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Joao Rito <joaovictor(dot)rito(at)gmail(dot)com>
Cc: Greg Burd <greg(at)burd(dot)me>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Hayato Kuroda <kuroda(dot)hayato(at)fujitsu(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com>
Subject: Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE)
Date: 2026-11-13 10:41:53
Message-ID: CALDaNm2XiW-km_8EMzrOM-ohThLJRoBveHGxy1_Ag=TiFg9qnQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 12 Nov 2026 at 21:43, Joao Rito <joaovictor(dot)rito(at)gmail(dot)com> wrote:
>
> Hi Greg,
>
> Thank you for the v7 patch and the new recovery test.
>
> I tested v7 on a local build. While running 061_hash_vacuum_insert_crc on
> Linux (ext4, meson build), subtest 2 failed for me with:y
>
> pg_waldump: error: invalid WAL segment size in WAL file
> "000000010000000000000002" (0 bytes)
>
> Both LSNs are in segment ...0001, and segment ...0002 is a zero-filled
> 16 MB file. When --path is a directory, pg_waldump seems to read the
> segment size from the first WAL file readdir() returns, so the result
> depends on directory order (here 0002 came first).
>
> Passing the segment file for $start_lsn (for example from pg_walfile_name)
> worked for me by hand. Subtest 3 passed and I saw no CRC problem. I did
> not apply the change to the test and rerun it under meson.

Thanks for the comment, this is addressed in the v8 version patch attached.
Apart from that, the following changes were done:
1) prepared back branch patches for the 0001 patch.
2) The test 068 was renamed to the next available 061 test file.
3) Most of the test code was common in
hash_torn_primary_page_delete_first and
hash_torn_primary_page_standby, merged them to a single test
4) the test added along with 0001 was not passing with the first patch
alone, fixed it so that the first patch can be committed separately.

Regards,
Vignesh

Attachment Content-Type Size
v8-0001-Fix-hash-index-redo-reading-a-torn-primary-bucket.patch application/octet-stream 16.8 KB
v8-0003-Add-a-recovery-test-for-the-hash-WAL-pin-only-buc.patch application/octet-stream 11.7 KB
v8-0002-Don-t-register-pin-only-primary-bucket-pages-in-h.patch application/octet-stream 24.9 KB
v8-0004-Remove-REGBUF_NO_CHANGE.patch application/octet-stream 5.1 KB
v8_REL15-0001-Fix-hash-index-redo-reading-a-torn-primary-.patch application/octet-stream 16.3 KB
v8_REL17-0001-Fix-hash-index-redo-reading-a-torn-primary-.patch application/octet-stream 16.8 KB
v8_REL19-0001-Fix-hash-index-redo-reading-a-torn-primary-.patch application/octet-stream 16.8 KB
v8_REL16-0001-Fix-hash-index-redo-reading-a-torn-primary-.patch application/octet-stream 16.8 KB
v8_REL18-0001-Fix-hash-index-redo-reading-a-torn-primary-.patch application/octet-stream 16.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-11-13 10:50:10 Re: transaction_timeout is not enforced during ClientWrite
Previous Message Peter Eisentraut 2026-11-13 10:37:40 -Wformat-nonliteral