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