Re: Rework the way multixact truncations work

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Rework the way multixact truncations work
Дата
Msg-id 20150922234500.GD1573@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Rework the way multixact truncations work  (Andres Freund <andres@anarazel.de>)
Ответы Re: Rework the way multixact truncations work  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2015-09-23 01:24:31 +0200, Andres Freund wrote:
> I think we put at least three layers on bandaid on this issue since
> 9.3.2, and each layer made things more complicated.

2a9b01928f193f529b885ac577051c4fd00bd427 - Cope with possible failure of the oldest MultiXact to exist.
5bbac7ec1b5754043e073a45454e4c257512ce30 - Advance the stop point for multixact offset creation only at checkpoint.
9a28c3752c89ec01fb8b28bb5904c6d547507fda - Have multixact be truncated by checkpoint, not vacuum
215ac4ad6589e0f6a31cc4cd867aedba3cd42924 - Truncate pg_multixact/'s contents during crash recovery

At least these are closely related to the fact that truncation isn't WAL
logged. There are more that are tangentially related. We (primarily me,
writing the timewise first one) should have gone for a new WAL record
from the start. We've discussed that in at least three of the threads
around the above commits...



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Less than ideal error reporting in pg_stat_statements
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Less than ideal error reporting in pg_stat_statements