On 08.06.2011 12:36, Dan Ports wrote:
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.
I think that is only relevant for queries like "SELECT * FROM table
WHERE ctid = '(12,34)'. You might expect that we take a lock on that
physical part of the heap, so that an INSERT that falls on that slot
would conflict, but one that falls elsewhere does not. At the moment, a
TidScan only takes a predicate lock tuples that exist, it doesn't try to
lock the range like an IndexScan would.
The physical layout of the table is an implementation detail that the
application shouldn't care about, so I don't feel sorry for anyone doing
that. Maybe it's worth mentioning somewhere in the docs, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
