Re: [WIP PATCH] Lazily assign xids for toplevel Transactions

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> What do you think about solving the requirements of the *first* waiting
>> phase (Where we wait for current ShareLock holders) inside the lock manager?
>> The only real downside I can see is that I feel uneasy about messing with
>> that code... It seems to be subtle, and quick to anger ;-)
>
> It sounded pretty dubious to me. The problem is that we don't want to
> wait until we could actually *get* the lock, we only want to wait out
> the conflicting xacts that existed when we looked. This is important
> because there might be a steady stream of new xacts acquiring
> conflicting locks (ie, a steady stream of writers), and we don't want to
> either block them, or have to hope for a window where there are none.
> But the lock manager does not currently track who acquired a lock when,
> and I think it would add a lot of usually-wasted overhead to do that.
>
> I spent a fair amount of time yesterday trying to think of alternative
> solutions, and didn't really think of much. The core reason why C.I.C.
> is implemented the way it is is that it's entirely possible that there
> will be a deadlock with some other process (ie, the other process is
> old enough that we must wait for it, but it's blocked trying to acquire
> some lock that conflicts with our ShareUpdateExclusiveLock). Thus,
> waiting by trying to acquire XID locks is a good idea because it
> automatically detects deadlock, and may even be able to escape the
> deadlock by wait-queue rearrangement. (I'm not certain that the latter
> is applicable in any situation C.I.C. would get into, but I'm not
> certain it's not, either.) Schemes involving "sleep awhile and check
> the ProcArray again" are right out because they fail to detect
> deadlock. Everything else I could think of involved special new
> lockmanager features that would have to still preserve the ability
> to handle deadlocks, which didn't sound like something I want to
> tackle for this.
>
> So on the whole the extra transaction identifier seems to be the
> way to go. I haven't looked at how that interacts with HOT though.

Ok, I'll update the patch to use your global id plus local id
idea than, and remove TemporaryTransactionIds.

greetings, Florian Pflug