Re: Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()

On Mon, Nov 09, 2015 at 10:40:07PM +0100, Andres Freund wrote:
> /*
> * Optional array of WAL flush LSNs associated with entries in the SLRU
> * pages. If not zero/NULL, we must flush WAL before writing pages (true
> * for pg_clog, false for multixact, pg_subtrans, pg_notify). group_lsn[]
> * has lsn_groups_per_page entries per buffer slot, each containing the
> * highest LSN known for a contiguous group of SLRU entries on that slot's
> * page.
> */
> XLogRecPtr *group_lsn;
> int lsn_groups_per_page;
>
> Uhm. multixacts historically didn't need to follow the
> write-WAL-before-data rule because it was zapped at restart. But it's
> now persistent.
>
> There are no comments about this choice anywhere in multixact.c, leading
> me to believe that this was not an intentional decision.

Here's the multixact.c comment justifying it:

* XLOG interactions: this module generates an XLOG record whenever a new
* OFFSETs or MEMBERs page is initialized to zeroes, as well as an XLOG record
* whenever a new MultiXactId is defined. This allows us to completely
* rebuild the data entered since the last checkpoint during XLOG replay.
* Because this is possible, we need not follow the normal rule of
* "write WAL before data"; the only correctness guarantee needed is that
* we flush and sync all dirty OFFSETs and MEMBERs pages to disk before a
* checkpoint is considered complete. If a page does make it to disk ahead
* of corresponding WAL records, it will be forcibly zeroed before use anyway.
* Therefore, we don't need to mark our pages with LSN information; we have
* enough synchronization already.

The comment's justification is incomplete, though. What of pages filled over
the course of multiple checkpoint cycles?