Re: Unlogged bloom indexes break after crash recovery

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 it
>
> Since commit ccadf73163c <https://github.com/postgres/postgres/commit/
> ccadf73163ca88bdaa74b8223d4dde05d17f550b> (discussion: https://
> www.postgresql.org/message-id/6e5bbc08-cdfc-
> b2b3-9e23-1a914b9850a9(at)iki(dot)fi <https://www.postgresql.org/message-
> id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9(at)iki(dot)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