Excerpts from Robert Haas's message of lun feb 06 13:19:14 -0300 2012: > > On Mon, Feb 6, 2012 at 9:31 AM, Alvaro Herrera > <alvhe...@commandprompt.com> wrote: > >> Suppose you have a tuple A which is locked by a series of transactions > >> T0, T1, T2, ...; AIUI, each new locker is going to have to create a > >> new mxid with all the existing entries plus a new one for itself. > >> But, unless I'm confused, as it's doing so, it can discard any entries > >> for locks taken by transactions which are no longer running. > > > > That's correct. But the problem is a tuple that is locked or updated by > > a very old transaction that doesn't commit or rollback, and the tuple is > > never locked again. Eventually the Xid could remain live while the mxid > > is in wraparound danger. > > Ah, I see. I think we should probably handle that the same way we do > for XIDs: try to force autovac when things get tight, then start > issuing warnings, and finally just refuse to assign any more MXIDs.
Agreed. > Another thing that might make sense, for both XIDs and MXIDs, is to > start killing transactions that are preventing vacuum/autovacuum from > doing their thing. This could mean either killing the people who are > holding back RecentGlobalXmin, so that we can actually freeze the old > stuff; or killing people who are holding a conflicting lock, using the > recovery-conflict stuff or some adaptation of it. Yeah -- right now we only emit some innocuous-looking messages, which I've seen most people to ignore until they get bitten by a forced anti-wraparound vacuum. It'd be nice to get more agressive about that as the situation gets more critical. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers