From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SSI heap_insert and page-level predicate locks |
Date: | 2011-06-08 22:29:13 |
Message-ID: | 4DEFB169020000250003E3BD@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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.
Absolutely correct. Patch attached.
-Kevin
Attachment | Content-Type | Size |
---|---|---|
ssi-heap-insert-fix-1.patch | text/plain | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Brar Piening | 2011-06-08 22:36:44 | Re: smallserial / serial2 |
Previous Message | Mark Kirkwood | 2011-06-08 22:20:15 | Re: gcc 4.6 and hot standby |