From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com> |
Cc: | "Greg Stark" <greg(dot)stark(at)enterprisedb(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "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-06-01 22:32:00 |
Message-ID: | 4A241090.EE98.0025.1@wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> So, at least theoretically, anyone who had a traffic mix similar to
> TPCE would benefit. Particularly, some long-running serializable
> transactions thrown into a mix of Read Committed and Repeatable
> Read transactions, for a stored procedure driven application.
A belated thought. The proposed technique does yield different
behavior from traditional techniques for Read Committed and Repeatable
Read transactions which are run concurrently with Serializable
transactions. In traditional blocking techniques, even a Read
Committed transaction only sees the database in a state consistent
with some serial execution of the serializable transactions. As far
as I can see, this is not required by the SQL standard, but it might
possibly be an implementation artifact upon which some software might
rely. Any idea whether this is the case with the TPC-E benchmark?
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-01 22:39:05 | Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild |
Previous Message | Kevin Grittner | 2009-06-01 22:17:30 | Re: User-facing aspects of serializable transactions |