| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| 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:41:09 |
| Message-ID: | 4D2CA445.1080700@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-01-11 18:46:25 | Re: SSI and 2PC |
| Previous Message | Kevin Grittner | 2011-01-11 18:34:44 | Re: SSI and 2PC |