"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