On Wed, Jan 25, 2017 at 12:44 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: >> The way that SetTransactionIdLimit() now works looks a bit dangerous. >> xidWrapLimit, xidStopLimit, and xidWarnLimit are computed based on the >> passed-in oldestXid value and written straight into shared memory. >> But the shared memory copy of oldestXid could have a different value. >> I'm not sure if that breaks anything, but it certainly weakens any >> confidence callers might have had that all those values are consistent >> with each other. > > This was my main hesitation with the whole thing too. > > It's necessary to advance oldestXmin before we xlog the advance and > truncate clog, and necessary to advance the vacuum limits only > afterwards.
Well, that's why I tried to advocate that their should be two separate XID limits in shared memory: leave what's there now the way it is, and then add a new limit for "don't try to look up XIDs before this point: splat". I still think that'd be less risky. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers