Re: User-facing aspects of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Stark" <stark(at)enterprisedb(dot)com>
Cc: "<Markus Wanner" <markus(at)bluegap(dot)ch>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-06-02 15:56:26
Message-ID: 4A250559.EE98.0025.1@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Tue, Jun 2, 2009 at 2:44 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-06-02 16:03:26 Re: Managing multiple branches in git
Previous Message David E. Wheeler 2009-06-02 15:56:14 Re: Managing multiple branches in git