Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups
Дата
Msg-id CA+Tgmob3gkLvUzH=zD-Z+Tt2+z7Ep=ZHZf_Uq6=YbSDuYfOo4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vslookups  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vslookups  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Jan 19, 2017 at 10:06 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Peter Eisentraut wrote:
>
>> Also, I wonder whether we should not in vacuum.c change the order of the
>> calls of SetTransactionIdLimit() and SetMultiXactIdLimit() as well, just
>> to keep everything consistent.
>
> I am wary of doing that.  The current coding is well battle-tested by
> now, but doing things in the opposite order, not at all.  Pending some
> testing to show that there is no problem with a change, I would leave
> things as they are.  Probably said testing is too onerous for the
> benefit (which is just a little consistency).  What I fear is: what
> happens if a concurrent checkpoint reads the values between the two
> operations, and a crash occurs?  I think that the checkpoint might save
> the updated values, so after crash recovery the truncate would not be
> executed, possibly leaving files around.  Leaving files around might be
> dangerous for multixacts at least (it's probably harmless for xids).

Don't both SLRUs eventually wrap?  If so, leaving file around seems
dangerous for either in equal measure.

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication