On Thu, Oct 13, 2016 at 6:19 AM, Kevin Grittner <kgrittn@xxxxxxxxx> wrote: >> 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. It sounds like you're talking about the original complaint about a multi-value INSERT. It took me a minute to decide that that's probably what you meant, because everyone already agrees that that isn't okay -- you don't need to convince me. We must still determine if a fix along the lines of the one proposed by Thomas is basically acceptable (that is, that it does not clearly break any documented guarantees, even if it is overly strict). Separately, I'd be interested in seeing how specifically we could do better with the patch that you have in the works for this. In general, I see value in reducing false positives, but I don't understand why your concern here isn't just about preferring to keep them to a minimum (doing our best). In other words, I don't understand why these false positives are special, and I'm still not even clear on whether you are actually arguing that they are special. (Except, of course, the multi-value case -- that's clearly not okay.) So, with the fix proposed by Thomas applied, will there be any remaining false positives that are qualitatively different to existing false positive cases? And, if so, how? -- Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
