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

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 <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
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +