From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage() |
Date: | 2015-11-09 21:40:07 |
Message-ID: | 20151109214007.GF32209@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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, 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-11-09 22:04:12 | storage/buffer/README docs about buffer replacement are out of date |
Previous Message | Simon Riggs | 2015-11-09 19:47:34 | Re: eXtensible Transaction Manager API |