On Fri, 31 Jan 2003, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> > The problem with this is that it's probably pretty unimplementable,
>
> Yeah. This shows the difference between what we do and true
> serialization. An academic would tell you that true serialization
> requires predicate locking --- that is, as soon as transaction T1 has
> done a "SELECT ... WHERE foo", then concurrent transaction T2 must wait
> for T1 if it tries to insert *or remove* a row that would satisfy foo.
Right, or you need to do some kind of thing where instead of locking, you
keep track of what predicate violations have occurred and prevent cycles
by killing a transaction in the cycle with a serialization error
(basically the optimistic locking version of the above I'd guess). The
enforcement would be a nightmare in any case if you wanted perfect results
(no false positives), especially given functions and custom aggregates
where you might have to run the results again after data modifications and
see if they've changed since all you get is a black box.
