| 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: | Whole Thread | Raw Message | 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 |