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
dataentered 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
MEMBERspages to disk before a* checkpoint is considered complete.  If a page does make it to disk ahead* of
correspondingWAL records, it will be forcibly zeroed before use anyway.* Therefore, we don't need to mark our pages
withLSN information; we have* enough synchronization already.
 

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