From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | s post <sbmpost(at)science(dot)uva(dot)nl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: unserializable transaction? |
Date: | 2004-08-20 01:03:55 |
Message-ID: | 14504.1092963835@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
s post <sbmpost(at)science(dot)uva(dot)nl> writes:
> Recently I posted "notes on SERIALIZABLE transactions". In these notes I
> state that one should use SELECT FOR UPDATE on all accessed data items to
> execute SERIALIZABLE transactions. I now seem to have found a schedule
> that cannot be serialized in this way.
Congratulations, you've discovered the need for predicate locking ;-)
I'm not sure why this wasn't well-documented long ago, but I've added
something to the 8.0 docs about it:
http://developer.postgresql.org/docs/postgres/transaction-iso.html#MVCC-SERIALIZABILITY
> If so, then I suppose this is a bug?
We do not consider it a bug ... at least, doing predicate locking is not
on our list of desirable changes. In practice, using explicit table
locking when necessary is a much more effective solution to these types
of problems.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-20 01:13:54 | Re: int8, primary key, seq scan |
Previous Message | Dave Cramer | 2004-08-20 00:51:03 | Re: int8, primary key, seq scan |