From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups |
Date: | 2017-01-19 16:50:19 |
Message-ID: | CA+Tgmob3gkLvUzH=zD-Z+Tt2+z7Ep=ZHZf_Uq6=YbSDuYfOo4g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 19, 2017 at 10:06 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-01-19 16:53:02 | Re: [HACKERS] SEGFAULT in HEAD with replication |
Previous Message | Robert Haas | 2017-01-19 16:47:53 | Re: Too many autovacuum workers spawned during forced auto-vacuum |