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?

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to