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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()
Дата
Msg-id 20151109214007.GF32209@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: eXtensible Transaction Manager API
Следующее
От: Andres Freund
Дата:
Сообщение: storage/buffer/README docs about buffer replacement are out of date