Re: Predicate locking

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Predicate locking
Date: 2011-05-03 06:48:08
Message-ID: 20110503064807.GB85173@csail.mit.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 03, 2011 at 01:36:36PM +0900, Vlad Arkhipov wrote:
> Then I commited the both and the second one raised an exception:
> ERROR: could not serialize access due to read/write dependencies among
> transactions
> SQL state: 40001
>
> However the second transaction does not access the records that the
> first one does. If I had predicate locks I could avoid this situation by
> locking the records with the specified id.

Yes, you're right -- the current implementation of SSI only locks
indexes at the granularity of index pages. So although those
transactions don't actually access the same records, they're detected
as a conflict because they're on the same index page. Of course, on a
larger table this might be less likely to happen.

Getting this down to index-key and index-gap lock granularity is on
the todo list. Our focus in the initial SSI development has been to get
something that's functionally correct and stable before optimizing it.
I'm hoping to get some time to work on index-key locking for 9.2, as I
expect it will make a significant performance difference.

Dan

--
Dan R. K. Ports MIT CSAIL http://drkp.net/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-05-03 07:30:26 Re: FDW table hints
Previous Message Johann 'Myrkraverk' Oskarsson 2011-05-03 06:46:26 DLL export with mingw-w64: currently a no-op