[Bizgres-general] Another use case

[Mark Kirkwood]

Gavin Sherry wrote:
> On Fri, 11 Aug 2006, Mark Kirkwood wrote:
>
>   
>> Mark Kirkwood wrote:
>>     
>> Actually Gavin is correct, we have to be a bit more subtle than that -
>> merely dropping the [Row]ExclusiveLock could leave the target relation
>> without any lock at all. However, I think taking an AccessShareLock and
>> *then* dropping the [Row]ExclusiveLock should work as intended.
>>     
>
> I wonder if there's a deadlock condition where you could have two queries
> where query 1 is being demoted from RowExclusive to AccessShare and query
> 2 is being promoted from AccessShare to RowExclusive...
>
> Actually, it doesn't seem like there is because query 1 will definately
> get the AccessShare lock. However, take a good look at some of the
> comments in LockAcquire/Release because lock demotion is not something the
> code currently expects to happen, it seems.
>
>   
>
Yeah - the downgrading seems unlikely to cause any problems, however the 
upgrade at wakeup is quite subtle - as there is a possible lock order 
reversal between the resource and standard lock acquisition to circumvent.

To clarify, currently the code acquires (most of) the standard locks at 
parse/analyze and *then* the resource lock after that. Simply plugging 
in code to upgrade the standard locks at wakeup means that essentially 
this section of code will hold a resource lock *before* (re)acquiring 
standard locks.... not nice, as we have reversed the order and can 
therefore deadlock.  I'm concerned that attempting to work around this 
may cause as many problems as we solve :-o.

Cheers

Mark