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
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 |