Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage() - Mailing list pgsql-hackers

From Andres Freund
Subject Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()
Date
Msg-id 20151109214007.GF32209@alap3.anarazel.de
Whole thread Raw
Responses Re: Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Hi,

By happenstance I just had slru.h open after lunch and noticed the
following comment:/* * Optional array of WAL flush LSNs associated with entries in the SLRU * pages.  If not zero/NULL,
wemust flush WAL before writing pages (true * for pg_clog, false for multixact, pg_subtrans, pg_notify).  group_lsn[] *
haslsn_groups_per_page entries per buffer slot, each containing the * highest LSN known for a contiguous group of SLRU
entrieson 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.

Right now I think the "missing" flushes are fairly unlikely to cause
problems in practice. Mostly because the multixact SLRUs are essentially
append only.

But I'd like some more brains to think about potential danger. If we
decide it's ok, let's update the comments.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: eXtensible Transaction Manager API
Next
From: Andres Freund
Date:
Subject: storage/buffer/README docs about buffer replacement are out of date