Re: SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks

SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks

Heikki Linnakangas  wrote:
> heap_insert() calls CheckForSerializableConflictIn(), which checks if

> there is a predicate lock on the whole relation, or on the page we're

> inserting to. It does not check for tuple-level locks, because there

> can't be any locks on a tuple that didn't exist before.
> 
> AFAICS, the check for page lock is actually unnecessary. A page-level

> lock on a heap only occurs when tuple-level locks are promoted. It is

> just a coarser-grain representation of holding locks on all tuples on

> the page, *that exist already*. It is not a "gap" lock like the index

> locks are, it doesn't need to conflict with inserting new tuples on
the 
> page. In fact, if heap_insert chose to insert the tuple on some other

> heap page, there would have been no conflict.
 
Absolutely correct.  Patch attached.
 
-Kevin

Re: SSI heap_insert and page-level predicate locks

Re: SSI heap_insert and page-level predicate locks