Re: How to reproduce serialization failure for a read only transaction.

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Dan Ports <drkp(at)csail(dot)mit(dot)edu>, AK <alkuzo(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to reproduce serialization failure for a read only transaction.
Date: 2014-01-08 21:14:27
Message-ID: 1389215667.82417.YahooMailNeo@web122303.mail.ne1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Jan7, 2014, at 20:11 , Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:

>> Yeah, neither of the provided examples rolled back the read only
>> transaction itself;
>
> Actually, the fixed version [1] of my example does.
>
> [1] http://www.postgresql.org/message-id/8721AAD3-7A3A-4576-B10E-F2CBD1E5337A@phlo.org

Due to my lame email provider, that post didn't show for me until I
had already replied.  :-(  You had already showed an example almost
exactly like what I described in my post.  I tweaked it a bit more
for the Wiki page to show more clearly why SSI has to care about
what the writing transaction reads.  For all the database engine
knows, what was read contributed to whether the application allowed
it to successfully commit.  By using the value from the SELECT in
the UPDATE it is easier to see why it matters, although it needs to
be considered either way.

In other words, we seem to be in full agreement, just using
different language to describe it.  :-)

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2014-01-08 21:29:14 Re: nested hstore patch
Previous Message Bruce Momjian 2014-01-08 21:08:10 Re: Standalone synchronous master