Unlogged bloom indexes break after crash recovery
Hi all,
I noticed that bloom indexes are not properly WAL-looged on unlogged tables
and attached is my attempt at fixing it
Since commit ccadf73163c
<https://github.com/postgres/postgres/commit/ccadf73163ca88bdaa74b8223d4dde05d17f550b>
(discussion:
/messages/by-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi),
`contrib/bloom` index AM's blbuildempty() wrote the metapage of the init
fork through generic WAL, which emits no WAL record for an unlogged
relation.
The init fork must be WAL-logged as it is used to recreate main fork of an
unlogged relation after a crash.
Without this fix, after a crash, an unlogged and bloom-indexed relation
gets a zero-ed out index meta page. As a result, insertions and index scans
fail with "Relation is not a bloom index" or "could not read blocks 0..0",
until an index rebuild.
Narek
--
Attachments:
t254533_10002-Fix-init-fork-unlogged-table-WAL-logging-of-bloom-in.patchapplication/octet-stream; name=0002-Fix-init-fork-unlogged-table-WAL-logging-of-bloom-in.patchDownload+16-7
0001-Add-tests-for-crash-recovery-with-unlogged-bloom-ind.patchapplication/octet-stream; name=0001-Add-tests-for-crash-recovery-with-unlogged-bloom-ind.patchDownload+22-1
On 03/11/2026 03:06, Narek Galstyan wrote:
Hi all,
I noticed that bloom indexes are not properly WAL-looged on unlogged
tables and attached is my attempt at fixing itSince commit ccadf73163c <https://github.com/postgres/postgres/commit/
ccadf73163ca88bdaa74b8223d4dde05d17f550b> (discussion: https://
www.postgresql.org/message-id/6e5bbc08-cdfc-
b2b3-9e23-1a914b9850a9@iki.fi <https://www.postgresql.org/message-
id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi>), `contrib/bloom` index
AM's blbuildempty() wrote the metapage of the init fork through generic
WAL, which emits no WAL record for an unlogged relation.The init fork must be WAL-logged as it is used to recreate main fork of
an unlogged relation after a crash.Without this fix, after a crash, an unlogged and bloom-indexed relation
gets a zero-ed out index meta page. As a result, insertions and index
scans fail with "Relation is not a bloom index" or "could not read
blocks 0..0", until an index rebuild.
Yep, my fault with ccadf73163c.
Your proposed fix fixes it, but only for contrib/bloom. Any other
indexam using generic WAL would also need to know that they cannot use
generic WAL for the init fork. How about the attached, to teach
GenericXLogFinish() to WAL log the init fork, instead?
- Heikki