From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Two-phase commit |
Date: | 2004-10-06 22:59:54 |
Message-ID: | 416478EA.9080202@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>
>>>At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
>>>think you have missed a bet in that it needs to be possible to issue
>>>"COMMIT PREPARED gid" for the same gid several times without error.
>
>
>>Isn't this usually where the GTM would issue "recover" requests to
>>determine the state of the individual resources involved in the global
>>transaction, and then only commit/abort the resources that need it? (I
>>think the equivalent in Heikki's work is a SELECT of the
>>pg_prepared_xact view)
>
>
> Well, the question is how long must the individual databases retain
> state with which to answer "recover" requests. I don't like "forever",
> so I'm proposing that there should be an explicit command to say "you
> can forget about this gid".
As I understand it, you don't need to keep state for committed txns,
it's only the prepared-but-not-yet-resolved txns that you have to
respond to a recover request with.
Then it seems like we already have a "forget about this GID" command for
prepared transactions: ROLLBACK PREPARED.
Probably the next question is, do we want a database-side timeout on how
long prepared txns can stay alive before being summarily rolled back?
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2004-10-06 23:06:52 | Re: Two-phase commit |
Previous Message | Tom Lane | 2004-10-06 22:50:42 | Re: Two-phase commit |
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2004-10-06 23:06:52 | Re: Two-phase commit |
Previous Message | Tom Lane | 2004-10-06 22:50:42 | Re: Two-phase commit |