Re: [PATCH] Lazy xid assingment V2

"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> Tom Lane wrote:
>> I don't much like this, since as I mentioned before I don't think
>> MyProc->xmin is going to be constant over a whole transaction for
>> long. I don't think xid_age is performance-critical in any way,
>> so I'd vote for letting it force XID assignment.

> Hm... I agree that xid_age is probably not performance-critical.
> I guess it's more the complete counter-intuitivity of forcing
> xid assignment in some arbitrary function thats bugging me a bit.

Well, I don't see it as arbitrary --- we're trying to hide the fact that
XIDs are assigned lazily from user-visible behavior.

>>> Locks on ResourceOwnerIds are not saved to the 2PC state file on PREPARE, since
>>> the RID or a transaction will be reused at time point after it was prepared.
>>
>> Hmm. I think this is all right since we don't actually need to wait for
>> a prepared xact, but it still seems like a wart.
>
> It certainly is a wart, though but removing it will create a bigger one
> I fear... The only other I idea I had was to make locks on RIDs session
> locks, and to drop them explicitly at toplevel commit and abort time,
> and that certainly has a quite high warty-ness score...

Hmm. I was thinking that we could just not do anything special here,
but on second thought I see the problem: on crash and restart we are
intending to restart the session ID counter from zero, which creates
a significant probability of some session conflicting with a VXID
lock held by a prepared xact. So I guess filtering the VXID lock
out of the set sent to disk is probably the best answer. There's
definitely no need for the prepared xact to continue to hold that
lock after crash/restart.

regards, tom lane