Skip site navigation (1) Skip section navigation (2)

Re: User-facing aspects of serializable transactions

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-05-28 12:24:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut wrote:
> On Thursday 28 May 2009 04:49:19 Tom Lane wrote:
>> Yeah.  The fundamental problem with all the "practical" approaches I've
>> heard of is that they only work for a subset of possible predicates
>> (possible WHERE clauses).  The idea that you get true serializability
>> only if your queries are phrased just so is ... icky.  So icky that
>> it doesn't sound like an improvement over what we have.
> Is it even possible to have a predicate locking implementation that can verify 
> whether an arbitrary predicate implies another arbitrary predicate?

I don't think you need that for predicate locking. To determine if e.g 
an INSERT and a SELECT conflict, you need to determine if the INSERTed 
tuple matches the predicate in the SELECT. No need to deduce anything 
between two predicates, but between a tuple and a predicate.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Stephen FrostDate: 2009-05-28 12:26:47
Subject: Re: search_path vs extensions
Previous:From: Stephen FrostDate: 2009-05-28 12:24:21
Subject: Re: search_path vs extensions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group