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

Kevin Grittner-5 wrote
> "

> gavin.panella@

> " <

> gavin.panella@

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