On 14 March 2017 at 05:43, Robert Haas <robertmhaas@gmail.com> wrote:
> For example, suppose vacuum #1 comes along, advances the limits,
> truncates clog, and then gets descheduled. Now vacuum #2 comes along,
> advances the limits further, and then gets descheduled. Now vacuum #1
> wakes up and calls SetTransactionIdLimit() and prematurely advances
> xidWrapLimit. Oops.
Mm, right. And without a lock held from when oldestXid advances
through to completion of clog truncation, then taking the same lock in
SetTransactionIdLimit, there's not really a way around it.
I'm embarrassed not to have seen that.
Doing things the other way around, per the earlier patch, can cause
SetTransactionIdLimit to not to advance as far as it should.
OK, I'm convinced, a new field is safer, even if it's redundant most
of the time.
I'll introduce a new LWLock, ClogTruncationLock, which will be held
from when we advance the new clogOldestXid field through to when clog
truncation completes.
Most of the rest can stay the same. In particular, the expanded xlog
record for clog truncation will still be required.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services