From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yaroslav <ladayaroslav(at)yandex(dot)ru> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: How do concurrent inserts work? |
Date: | 2014-12-27 17:52:17 |
Message-ID: | 28189.1419702737@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Yaroslav <ladayaroslav(at)yandex(dot)ru> writes:
> http://postgresql.nabble.com/Re-BUG-12330-ACID-is-broken-for-unique-constraints-td5832085.html
> I've come to conclusion that I don't understand PostgreSQL transaction
> isolation. :(
In your example, you've already committed the other insertion of "2",
right? So the serializable transaction *must* fail to insert "2".
The current coding chooses to give you a "duplicate key" error on
the grounds that that's more helpful than a generic "serialization
failure" error. The debate around bug #12330 is about whether that
is the best choice of error code ... but one way or the other, you're
going to get an error. On the other hand, the SELECT step isn't going
to show you the "2", because it's in the future so far as the
transaction's snapshot is concerned.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Yaroslav | 2014-12-27 19:37:28 | Re: How do concurrent inserts work? |
Previous Message | David G Johnston | 2014-12-27 16:08:12 | Re: How do concurrent inserts work? |