[Bizgres-general] Another use case

[Mark Kirkwood]

Jim C. Nasby wrote:
> On Thu, Aug 10, 2006 at 12:00:24PM +1200, Mark Kirkwood wrote:
>   
>>     
>> No, not for Postgres or Bizgres anyway - see my previous mail about 
>> RowExclusive locks.  Other sessions can happily carry on updating 
>> 'big_hairy_table' :-).  I think what is happening is that a RowExclusive 
>> lock is created at parse time (or thereabouts), but no tuple locks are 
>> taken till the executor is run to identify said tuples.
>>     
>
> DOH! I should have said DDL in there, not DML. Not quite as big a deal,
> but still something that needs to be considered. Maybe there needs to be
> a way to force statements that are sitting in-queue to drop their table
> locks and then re-aquire them (and deal with the consequences).
>   


Currently I'm only considering SELECT, INSERT, UPDATE, DELETE, DECLARE 
for locking, as I didn't want to mess with DDL.

However, I'm looking at your suggestion, as it may be generally good to 
be able to unlock all target relations in the query(s) before waiting on 
a resource lock. It is pretty easy to find out what the target relations 
are for a query (examine range table entry for the query's listed target 
relation index), but determining what sort of lock is on the relation is 
not so obvious (could scan the lock hash, but may find several locks of 
different modes), I may have to punt for RowExclusive unless we are MPP!

Cheers

Mark