Re: freezing multixacts

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
> <alvherre(at)commandprompt(dot)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 <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support