Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts |
Дата | |
Msg-id | 17935.1405895946@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
|
Список | pgsql-bugs |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-07-20 18:16:51 -0400, Tom Lane wrote: >> My point is that the cutoff multi xid won't be new enough to remove >> non-LOCKED_ONLY (ie, post-9.3) mxids. > Why not? Afaics this will continue to happen until multixacts are > wrapped around once? So the cutoff multi will be new enough for that at > some point after the pg_upgrade? Before that happens, nextMultiXid will catch up with the minmxid = 1 values, and they'll be in the past, and then we're at the same point that we're at to begin with if we used 9.3.5 pg_upgrade. > Luckily in most cases full table vacuums triggered due to normal xids > will prevent bad problems though. Yeah. While it's not that comfortable to rely on that, we were reliant on that effect in every pre-9.3 branch, so I'm not terribly upset about it continuing to be the case in existing 9.3 installations. As long as they're not consuming mxids at a rate much greater than xids, they'll be all right; and things will be unconditionally safe once the freezing process has advanced far enough. regards, tom lane
В списке pgsql-bugs по дате отправления: