Re: User-facing aspects of serializable transactions

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

In response to

Browse pgsql-hackers by date

  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