Re: true serializability and predicate locking

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

In response to

Responses

Browse pgsql-hackers by date

  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