From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Zeugswetter Andreas DAZ SD <ZeugswetterA(at)spardat(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oliver Jowett <oliver(at)opencloud(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Two-phase commit |
Date: | 2004-10-07 10:57:23 |
Message-ID: | Pine.OSF.4.61.0410071353220.432862@kosh.hut.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 7 Oct 2004, Zeugswetter Andreas DAZ SD wrote:
>> Note that this is only really necessary because of Heikki's choice to
>> make the API work in terms of a user-assigned GID.
>
> This was not an arbitrary choice, but is required by most/all TX managers :-(
> I agree that it would be cleaner for the tx manager to keep such a map.
> Maybe the idea was for the gid's to be human readable since human intervention
> is rarely but still required with 2PC, especially in the case where the tx manager
> is unavailable/unrecoverable.
Actually, I think the reason is the following scenario:
1. TM tells DB to prepare for commit
2. DB connection dies after sending the message, but before the TM gets a
reply.
3. The TM now has no way to know if the transaction got prepared or not.
With a TM assigned transaction id, it works like this:
1. TM tells DB to prepare for commit with transaction id 1234
2. DB connection dies after sending the message, but before the TM gets a
reply.
3. TM reconnects, and asks the DB if the transaction 1234 is prepared or
not.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2004-10-07 11:15:44 | Re: Two-phase commit |
Previous Message | Greg Stark | 2004-10-07 09:30:25 | Re: database constraints |