On Wed, Oct 26, 2016 at 3:20 PM, Peter Geoghegan <pg@xxxxxxx> wrote: > On Mon, Oct 24, 2016 at 8:07 AM, Kevin Grittner <kgrittn@xxxxxxxxx> wrote: >> My initial thought is that since reducing the false positive rate >> would only help when there was a high rate of conflicts under the >> existing patch, and it would add code complexity and cost for the >> case where conflict rate is low, that we might want to just leave >> the current fix and see whether there are complaints from the field >> about the false positive rate. >> >> Reducing the rate of false positive serialization failures is a >> worthy goal, but it's gotta make sense from a cost/benefit >> perspective. > > What are your thoughts on the back-and-forth between myself and Tom > concerning predicate locks within heap_fetch_tuple() path last > weekend? I now think that there might be an outstanding concern about > ON CONFLICT DO NOTHING + SSI here. As far as I can see, Tom's fixes are all spot-on. It *might* be possible to call some special custom variant of heap_fetch() instead of the usual one here, but it would be very hard to prove that it was safe against introducing a bug in the serialization logic in all cases, and seems to me that it would be fragile against future changes. What's more, if we do decide that the false positive rate with the existing fix is too high, we would need to use the standard heap_fetch() function in implementing the more targeted logic. By the way, if we do get complaints from the field about performance problems from the false positives in this area, they would need to show that the hit was pretty severe to justify back-patching to any stable branches. We are talking about a performance tuning change, and one that is not necessarily a winner in all cases; such tuning is rarely back-patched to stable branches. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
