Re: User-facing aspects of serializable transactions - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: User-facing aspects of serializable transactions
Date
Msg-id 4A250559.EE98.0025.1@wicourts.gov
Whole thread Raw
In response to Re: User-facing aspects of serializable transactions  (Greg Stark <stark@enterprisedb.com>)
Responses Re: User-facing aspects of serializable transactions  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Greg Stark <stark@enterprisedb.com> wrote:
> On Tue, Jun 2, 2009 at 2:44 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> We have next to nothing which can be deleted after three months.
> That's reassuring for a courts system. :-)
> But i said "I could easily imagine". The point was that even in a
> big complex system with thousands of queries being constantly
> modified by hundreds of people, it's possible there might be some
> baseline rules.  Those rules can even be enforced using tools like
> views. So it's not true that no programmer could ever expect that
> they've written their code to ensure there's no risk of
> serialization failures.
Now I see what you're getting at.
I think we've beat this horse to death and then some.
Recap:
(1)  There is abstract, conceptual agreement that support for
serializable transactions would be A Good Thing.
(2)  There is doubt that an acceptably performant implementation is
possible in PostgreSQL.
(3)  Some, but not all, don't want to see an implementation which
produces false positive serialization faults with some causes, but
will accept them for other causes.
(4)  Nobody believes that an implementation with acceptable
performance is possible without the disputed false positives mentioned
in (3).
(5)  There is particular concern about how to handle repeated
rollbacks gracefully if we use the non-blocking technique.
(6)  There is particular concern about how to protect long-running
transactions from rollback.  (I'm not sure those concerns are confined
to the new technique.)
(7)  Some, but not all, feel that it would be beneficial to have a
correct implementation (no false negatives) even if it had significant
false positives, as it would allow iterative refinement of the locking
techniques.
(8)  One or two people feel that there would be benefit to an
implementation which reduces the false negatives, even if it doesn't
eliminate them entirely.  (Especially if this could be a step toward a
full implementation.)
Are any of those observations in dispute?
What did I miss?
Where do we go from here?
-Kevin


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Managing multiple branches in git
Next
From: Tom Lane
Date:
Subject: Re: Managing multiple branches in git