From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | Nicolas Barbier *EXTERN* <nicolas(dot)barbier(at)gmail(dot)com>, Robert Haas *EXTERN* <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: true serializability and predicate locking |
Date: | 2010-01-07 18:40:27 |
Message-ID: | 1262889627.14708.21.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-07 18:40:54 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | Robert Haas | 2010-01-07 18:28:33 | Re: Streaming replication and postmaster signaling |