Re: SSI heap_insert and page-level predicate locks - Mailing list pgsql-hackers

From Dan Ports
Subject Re: SSI heap_insert and page-level predicate locks
Date
Msg-id 20110608093657.GG26076@csail.mit.edu
Whole thread Raw
In response to SSI heap_insert and page-level predicate locks  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: SSI heap_insert and page-level predicate locks
Re: SSI heap_insert and page-level predicate locks
List pgsql-hackers
On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote:
> 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.

Yes, it's certainly unnecessary now, given that we never explicitly
take heap page locks, just tuple- or relation-level. 

The only thing I'd be worried about is that at some future point we
might add heap page locks -- say, for sequential scans that don't read
the entire relation -- and expect inserts to be tested against them.
I'm not sure whether we'd actually do this, but we wanted to keep the
option open during development.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/


pgsql-hackers by date:

Previous
From: Robert Creager
Date:
Subject: Re: [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
Next
From: Heikki Linnakangas
Date:
Subject: Re: SSI heap_insert and page-level predicate locks