Re: User-facing aspects of serializable transactions

Kevin Grittner wrote:
> Greg Stark <greg.stark@enterprisedb.com> wrote:
>> Without any real way to represent predicates this is all pie in the
>> sky
>  
> And this is 180% opposite from what I just heard at PGCon should be
> the focus of discussion at this point.  Let's get agreement on what
> would be nice user-facing behavior first.

Ok, here goes:

1. Needs to be fully spec-compliant serializable behavior. No anomalities.

2. No locking that's not absolutely necessary, regardless of the 
WHERE-clause used. No table locks, no page locks. Block only on 
queries/updates that would truly conflict with concurrent updates.

3. No "serialization errors" that are not strictly necessary.

4. Reasonable performance. Performance in single-backend case should be 
indistinguishable from what we have now and what we have with the more 
lenient isolation levels.

5. Reasonable scalability. Shouldn't slow down noticeably when 
concurrent updaters are added as long as they don't conflict.

6. No tuning knobs. It should just work.

Now let's discuss implementation. It may well be that there is no 
solution that totally satisfies all those requirements, so there's 
plenty of room for various tradeoffs to discuss. I think fully 
spec-compliant behavior is a hard requirement, or we'll find ourselves 
adding yet another isolation level in the next release to achieve it. 
The others are negotiable.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com