Re: true serializability and predicate locking - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: true serializability and predicate locking
Date
Msg-id 1262889627.14708.21.camel@jdavis
Whole thread Raw
In response to Re: true serializability and predicate locking  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: true serializability and predicate locking  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Thu, 2010-01-07 at 10:57 +0100, Albe Laurenz wrote:
> That sounds like major AI to me.
> What do you do if the condition involves user defined functions?

I don't see how it has anything to do with "user-defined" or not.

If the predicate is pure (immutable), it's no problem (regardless of
whether the function is user-defined or not) -- we test the predicate on
a new tuple the same way as we would test an existing tuple against a
WHERE clause in a scan.

If the predicate is stable, it can be considered to be immutable if we
keep the snapshot around and evaluate the predicate using the same
snapshot.

Volatile functions like random() don't make much sense in combination
with true serializability anyway. Perhaps volatile functions that just
have a side effect, but always return the same result, may still be
useful. If so, we could have a new classification for those kinds of
functions.

So I don't see this as a major problem.

My biggest worry is that a predicate locking scheme like this will be
fairly difficult to implement and expensive to execute.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standy introduced problem with query cancel behavior
Next
From: Tom Lane
Date:
Subject: Re: Hot Standy introduced problem with query cancel behavior