Re: WIP: Detecting SSI conflicts before reporting constraint violations

On Thu, Mar 10, 2016 at 1:50 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 3 February 2016 at 23:12, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>
>> It quacks suspiciously like a bug.
>
> Agreed
>
> What's more important is that is very publicly a bug in the eyes
> of others and should be fixed and backpatched soon.

I really am skeptical about back-patching this, since it changes
behavior that it is not inconceivable that someone, somewhere might
be relying on. Given the number of times the current behavior has
been reported as a bug, I might be persuaded otherwise, but it
"feels" wrong to me. I really don't like putting anything into a
minor release that might make someone reluctant to apply fixes for
serious bugs or security vulnerabilities.

> We have a maintenance release coming in a couple of weeks and I'd
> like to see this in there.

There is no shortage of people who would like to see that; but how
do we prove that we're not breaking things for anyone if we do
that?

> Let's set good standards for responsiveness and correctness.

This was discussed at the time SSI was implemented. In particular,
I cited section 4.2 of the paper by Jorwekar, et al.[1], where a
tool for static analysis of serialization anomalies allowed by
applications discounted (as false positives) apparent dangerous
structures when integrity constraints prevented any anomaly from
actually manifesting itself in the database. As discussed and
implemented at the time, no serialization anomalies can appear in
the database -- what we're talking about is improving the error
handling such that an application framework can automatically
handle transient errors without letting the end user (or even the
application software) see that there *was* a transient problem.
That's a nice feature to have, but I'm hard put to see where lack
of that feature constitutes a bug.

> I'd also like to see some theory in comments and an explanation
> of why we're doing this (code).

A reference to the 2007 VLDB paper would not be amiss there, along
with a brief description of the issue.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] http://www.vldb.org/conf/2007/papers/industrial/p1263-jorwekar.pdf
Sudhir Jorwekar, Alan Fekete, Krithi Ramamritham, S. Sudarshan.
Automating the Detection of Snapshot Isolation Anomalies.
VLDB ‘07, September 23-28, 2007, Vienna, Austria.