Re: WIP: Detecting SSI conflicts before reporting constraint violations

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: WIP: Detecting SSI conflicts before reporting constraint violations
Дата
Msg-id CACjxUsPL9FxC6LjiMx7Du6o8FgOnDx+VAKVTNTQ40GZbZRXozw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Detecting SSI conflicts before reporting constraint violations  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, Mar 10, 2016 at 1:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 3 February 2016 at 23:12, Thomas Munro <thomas.munro@enterprisedb.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. 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Logical decoding slots can go backwards when used from SQL, docs are wrong