| From: | Florian Pflug <fgp(at)phlo(dot)org> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org, Dan Ports <drkp(at)csail(dot)mit(dot)edu>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: SSI and 2PC |
| Date: | 2011-01-11 18:49:47 |
| Message-ID: | F8331FA1-26C6-4FB4-A9FF-75A3ED8120FA@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jan11, 2011, at 19:41 , Heikki Linnakangas 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.
The serialization error will occur even if T1 and T2 update *different* rows. This is
due to the SELECTs in the interleaved schedule above returning the state of T prior to
both T1 and T2. Which of course never the case for a serial schedule.
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-01-11 18:51:20 | Re: Allowing multiple concurrent base backups |
| Previous Message | Andreas Karlsson | 2011-01-11 18:47:55 | Re: Bug in pg_describe_object |