| From: | Florian Weimer <fweimer(at)bfk(dot)de> |
|---|---|
| To: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | "Kevin Grittner *EXTERN*" <Kevin(dot)Grittner(at)wicourts(dot)gov>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Update on true serializable techniques in MVCC |
| Date: | 2009-12-16 10:54:28 |
| Message-ID: | 82aaxji3yz.fsf@mid.bfk.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Albe Laurenz:
> That sounds like it should actually work.
If you have got an index, yes. It seems to me that it would make
locking behavior dependent on your query plan, too.
BTW, PostgreSQL could raise a different error when a unique constraint
violation is detected which involves a row which is not visible at the
current snapshot. At least in my limited experience, that would allow
applications to recover more easily if small transactions fail
(similar to what you have to do on deadlock). Right now (well, at
least with 8.3, haven't checked 8.4 yet), it's not possible to tell a
unique constraint violation caused by a phantom from an application
bug. (We currently faking this by retrying a fixed number of times
and bailing out if the error returned by PostgreSQL looks like a
unique constraint violation.)
--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2009-12-16 10:54:41 | Re: ECPG patch N+1, fix auto-prepare |
| Previous Message | Nicolas Barbier | 2009-12-16 10:37:42 | Re: Update on true serializable techniques in MVCC |