"Florian G. Pflug" <[EMAIL PROTECTED]> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
