Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
> On 8/11/10 1:18 PM +0300, Peter Eisentraut wrote:
>> On ons, 2010-08-11 at 10:54 +0300, Marko Tiikkaja wrote:
>>> Enforcing that kind of constraints without true serializability
>>> seems impractical.
>>
>> Yes, but that is being worked on, I understand.
>
> Correct. But you'd have to somehow make the constraints to be
> checked with true serializability, and that part of the original
> suggestion seemed to be completely missing. Not sure how hard
> that would be though.
I keep bumping into use cases where cool things could be done if you
could be sure that *all* transactions were being run at the fully
serializable transaction isolation level. Perhaps we could look at
a GUC (or initdb option, if people fear the consequences of changes
in an existing database) which not only defaults to serializable,
but silently ignores requests for other levels. If we only allowed
these constraints to be used in a database which was configured this
way, they would work fine.
Enforcing *part* of a transaction under full serializable isolation
seems totally infeasible, unless someone has a clever idea I'm
missing.
-Kevin