Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> On 11.01.2011 20:08, Florian Pflug wrote:
>> Unfortunately, it seems that doing things this way will undermine
>> the guarantee that retrying a failed SSI transaction won't fail
>> due to the same conflict as it did originally. Consider
>>
>> T1> BEGIN TRANSACTION ISOLATION SERIALIZABLE
>> T1> SELECT * FROM T
>> T1> UPDATE T ...
>> T1> PREPARE TRANSACTION
>>
>> T2> BEGIN TRANSACTION ISOLATION SERIALIZABLE
>> T2> SELECT * FROM T
>> T2> UPDATE T ...
>> -> Serialization Error
>>
>> Retrying T2 won't help as long as T1 isn't COMMITTED.
>
> T2 should block until T1 commits. I would be very surprised if it
> doesn't behave like that already. In general, a prepared
> transaction should be treated like an in-progress transaction - it
> might still abort too.
It shouldn't block if the updates were to different rows, which is
what I took Florian to mean; otherwise this would be handled by SI
and would have nothing to do with the SSI patch. SSI doesn't
introduce any new blocking (with the one exception of the READ ONLY
DEFERRABLE style we invented to support long-running reports and
backups, and all blocking there is at the front -- once it's
running, it's going full speed ahead).
-Kevin
