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
|
Список | 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 по дате отправления: