On Wed, Oct 12, 2016 at 8:32 PM, Peter Geoghegan <p...@bowt.ie> wrote: > On Wed, Oct 12, 2016 at 6:06 PM, Thomas Munro <thomas.mu...@enterprisedb.com> > wrote: >> But yeah, the existing code raises false positive serialization >> failures under SERIALIZABLE, and that's visible in the isolation test >> I posted: there is actually a serial order of those transactions with >> the same result. > > I was under the impression that false positives of this kind are > allowed by SSI. Why focus on this false positive scenario in > particular?
Every situation that generates a false positive hurts performance; we went to great lengths to minimize those cases. In addition, we made sure that at the point that a serialization failure is returned, that retrying the transaction from the start could not fail on the same combination of transactions, by ensuring that at least one transaction in the set had successfully committed, and that it was a transaction which had done writes. To generate a serialization failure on a single transaction has to be considered a bug, because a retry *CAN NOT SUCCEED*! This is likely to break many frameworks designed to work with serializable transactions. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
