Re: BUG #11919: Serializable isolation issue: one session seeing writes from another session.

From: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #11919: Serializable isolation issue: one session seeing writes from another session.
Date: 2014-11-11 02:47:10
Message-ID: 1415674030081-5826447.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kevin Grittner-5 wrote
> "

> gavin.panella@

> " &lt;

> gavin.panella@

> &gt; wrote:
>
>> I think I might have found a bug in PostgreSQL 9.3.5 relating to
>> serializable isolation, where code running within a savepoint can see
>> data committed in a second session after the commencement of the first,
>> but that data then "disappears" when the savepoint is rolled-back.
>
> Interesting. I see your point, yet I'm not sure what other
> behavior we could reasonably provide. Once the snapshot is set for
> the transaction, we can't use a different one which will show more
> recent activity, so that SELECT at the end *has* to return what it
> does. That leaves the question of whether the enforcement of the
> unique constraint within the savepoint should behave differently.
> Of course, you can make it do so by declaring it to be DEFERRED.
> There are several other weird things that can happen when they
> aren't deferred, for example:

Per the documentation (and, yes, it is not a protocol describing quote):

"This level emulates serial transaction execution for all committed
transactions; as if transactions had been executed one after another,
serially, rather than concurrently."

The concept of ROLLBACK TO SAVEPOINT seems like it would be undefined in a
serializable isolation level - in normal use unless the transaction is
self-flagellating concurrency errors causing rollbacks cannot occur. If
they do rollback should not be possible but a serializing error should
simply occur and force you to retry your transaction in its entirety.

Though I guess you could also interpret this as the second transaction was
serially executed temporally first and so while the INSERT in that
make-believe scenario would have succeeded the rollback is still a valid
command which then undoes that insert so that when you get to the SELECT
statement the things table is empty.

I don't know if the above violates the rules but I thought that while it
enforces some serial order the specific order is not necessarily in commit
order...

David J.

--
View this message in context: http://postgresql.nabble.com/BUG-11919-Serializable-isolation-issue-one-session-seeing-writes-from-another-session-tp5826436p5826447.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Franklin Schmidt 2014-11-11 06:58:57 hello
Previous Message Bruce Momjian 2014-11-11 01:56:37 Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year