From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | 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 15:06:43 |
Message-ID: | 20170119150643.577rcvnxj2yvaute@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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).
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2017-01-19 15:08:59 | Re: Patch to implement pg_current_logfile() function |
Previous Message | Stephen Frost | 2017-01-19 15:06:09 | Re: Re: Clarifying "server starting" messaging in pg_ctl start without --wait |