SSI heap_insert and page-level predicate locks

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Dan Ports <drkp(at)csail(dot)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: SSI heap_insert and page-level predicate locks
Date: 2011-06-08 08:23:48
Message-ID: 4DEF3194.6030305@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Ports 2011-06-08 08:59:43 Re: reindex creates predicate lock on index root
Previous Message Florian Pflug 2011-06-08 08:14:09 Re: [PATCH] Bug in XPATH() if expression returns a scalar value