On 14 March 2017 at 05:43, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
