Re: Two-phase commit

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Two-phase commit
Дата
Msg-id 1121.1097103042@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Two-phase commit  (Oliver Jowett <oliver@opencloud.com>)
Ответы Re: Two-phase commit  (Oliver Jowett <oliver@opencloud.com>)
Re: Two-phase commit  (Rod Taylor <pg@rbt.ca>)
Список pgsql-hackers
Oliver Jowett <oliver@opencloud.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".

Note that this is only really necessary because of Heikki's choice to
make the API work in terms of a user-assigned GID.  If PREPARE returned
the internal XID and then the COMMIT/ROLLBACK PREPARED statements took
the XID and not a GID, we could answer subsequent "recover" requests for
quite a long time by consulting pg_clog.  But then the transaction
monitor would have to maintain the map from its GIDs to per-node XIDs,
so unless it's going to have such functionality anyway, it's reasonable
to ask the database to keep the map.  (Either way, you're not going to
want to drop the mapping entry until the transaction monitor knows all
the commits are done.)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oliver Jowett
Дата:
Сообщение: Re: Two-phase commit
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: Two-phase commit