[Bizgres-general] Another use case

[Mark Kirkwood]

Jim Nasby wrote:
>
> Doesn't this lead to the following situation?
>
> UPDATE big_hairy_table SET field = big_scary_expression;
> planner grabs locks
> plan costs a lot, gets stuck in a queue
> every other DML query on big_hairy_table blocks, even if they were single-row updates
> query finally runs 10 minutes later
>
> BINGO! Priority inversion.
>
>   
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.

Cheers

Mark