Re: Rework the way multixact truncations work

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Rework the way multixact truncations work
Дата
Msg-id CA+TgmoZhtfYd_XGvUZYJhvPS30_kLAMXyFZyzJNLEFzNuf+WBw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rework the way multixact truncations work  (Andres Freund <andres@anarazel.de>)
Ответы Re: Rework the way multixact truncations work  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Sep 22, 2015 at 7:45 PM, Andres Freund <andres@anarazel.de> wrote:
> 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...

I'm not disagreeing with any of that.  I'm just disagreeing with you
on the likelihood that we're going to make things better vs. making
them worse.  But, really, I've said everything I have to say about
this.  You have a commit bit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Rework the way multixact truncations work