From: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Jeff Davis <pgsql(at)j-davis(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User-facing aspects of serializable transactions |
Date: | 2009-05-28 01:57:20 |
Message-ID: | A46E65F6-FAE0-474E-B5C6-185689312F09@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--
Greg
On 28 May 2009, at 02:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> writes:
>> Without any real way to represent predicates this is all pie in the
>> sky. The reason we don't have predicate locking is because of this
>> problem which it sounds like we're no closer to solving.
>
> 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.
>
I think you get "true serializability" in the sense that you take out
a full table lock on every read. I.e. Your transactions end up
actually serialized... Well it would be a bit weaker than that due to
the weak read-locks but basically you would get random spurious
serialization failures which can't be explained by inspecting the
transactions without understanding the implementation.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-05-28 01:58:33 | Re: User-facing aspects of serializable transactions |
Previous Message | Tom Lane | 2009-05-28 01:49:19 | Re: User-facing aspects of serializable transactions |