Added to TODO:
Consider improving serialized transaction behavior to avoid anomalies
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg01136.php
* http://archives.postgresql.org/pgsql-hackers/2009-06/msg00035.php
---------------------------------------------------------------------------
Kevin Grittner wrote:
> Greg Stark <[email protected]> wrote:
> > On Tue, Jun 2, 2009 at 2:44 PM, Kevin Grittner
> > <[email protected]> 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
>
> --
> Sent via pgsql-hackers mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
