[Bizgres-general] Another use case

[Mark Kirkwood]

Luke Lonergan wrote:
> Mark,
>    
>   
>
> Please be thick!
>
>   

Always easy to do  :-).

>> So we want to take resource 
>> locks at planning time?
>>     
>
> No, we don't! It's a lot better if this isn't the case.
>
> Our supposition as a group was that that's how it's done - which puzzled
> me given the topic of prepared statements, etc.
>
>   
>> The current implementation does not 
>> do this. The resource lock is taken in PortalRun, so a plan 
>> has been generated and returned
>> *before* a statement is queued. There is some subtlety with 
>> cursors, but the previous statement still holds!
>>     
>
> OK - does that mean that locks are not taken before a statement is
> queued?
>
>   

Hmm - there is some investigating to be done with exactly what happens 
with locks - I *do* see some RowExclusive locks popping up in pg_locks 
for queued DML statements - but as they have not been executed yet they 
do not block concurrent exclusive locking (i.e UPDATE/DELETE) to their 
would-be rowsets by other sessions, so it is like the lock entries are 
placeholders created at parse time, without the actual row offsets yet...

> If that's the case, it makes many things simpler.
>
>
>   

Hopefully!

Cheers

Mark