| 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: | 4A1E829B.3020406@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2009-05-28 12:26:47 | Re: search_path vs extensions |
| Previous Message | Stephen Frost | 2009-05-28 12:24:21 | Re: search_path vs extensions |