From: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SSI heap_insert and page-level predicate locks |
Date: | 2011-06-08 09:36:57 |
Message-ID: | 20110608093657.GG26076@csail.mit.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-06-08 09:45:35 | Re: SSI heap_insert and page-level predicate locks |
Previous Message | Dan Ports | 2011-06-08 08:59:43 | Re: reindex creates predicate lock on index root |