Well, from my point of view it is a special case of predicate locking
supported well by existing code, in this case the unique index (you said
that, I'm not familiar with the code). I don't see why this cannot be
capitalized on, to implement a sub-set of what predicate locking is,
based on the mechanism already existing. I guess most of the users who
need some kind of merge, replace, insert-or-update feature (or other
reasons to block inserts/updates on a specific row) would be happy for
now with the restriction that the condition must be backed by a unique
index.
So basically the only thing I'm trying to say is that a partial
implementation which might be easily implementable (I might be wrong
here), without too big performance penalties and covers a very valid
problem is better than chasing the complete solution which is too
complex to be implemented easily or it could be easily implemented but
then has performance disadvantages. The only thing is to be labeled
correctly so people don't expect something it isn't.
Of course all this is hand-waving, I can't really help even if I wanted,
my C skills are less then mediocre.
Cheers,
Csaba.
On Tue, 2005-11-15 at 12:14, Alvaro Herrera wrote:
> Csaba Nagy wrote:
>
> > session_1=> create table test (col smallint primary key);
> > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> > "test_pkey" for table "test"
> > CREATE TABLE
> > session_1=> begin;
> > BEGIN
> > cnagy=> insert into test values (1);
> > INSERT 165068987 1
> >
> > session_2=> begin;
> > BEGIN
> > session_2=> insert into test values (1);
> >
> > [session_2 is now waiting]
>
> This only happens because of the unique index. There's no predicate
> locking involved. The btree code goes some lengths to make this work;
> it would be probably simple to modify this to support MERGE or REPLACE
> on the limited cases where there's a UNIQUE index. Tom has already said
> this twice (on this thread only; he has already said it before IIRC.)
