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