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
> 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 wi
On Mon, Feb 6, 2012 at 9:31 AM, Alvaro Herrera
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, a
On Thu, Feb 2, 2012 at 4:33 AM, Alvaro Herrera wrote:
> However, there are cases where not even that is possible -- consider
> tuple freezing during WAL recovery. Recovery is going to need to
> replace those multis with other multis, but it cannot create new multis
> itself. The only solution h
Excerpts from Robert Haas's message of jue feb 02 11:24:08 -0300 2012:
> On Wed, Feb 1, 2012 at 11:33 PM, Alvaro Herrera
> wrote:
> > If there's only one remaining member, the problem is easy: replace it
> > with that transaction's xid, and set the appropriate hint bits. But if
> > there's mor
On Wed, Feb 1, 2012 at 11:33 PM, Alvaro Herrera wrote:
> So freezing multixacts is not all that easy. I mean, you just scan the
> page looking for multis lesser than the cutoff; for those that are dead,
> they can just be removed completely, but what about ones that still have
> members running?
So freezing multixacts is not all that easy. I mean, you just scan the
page looking for multis lesser than the cutoff; for those that are dead,
they can just be removed completely, but what about ones that still have
members running? This is pretty unlikely but not impossible.
If there's only o
