>>
>> Heuristics can not become the default behavior. A user should be given
>> an option to choose a heuristic, and he should be aware of the
>> pitfalls when using this heuristic. I guess, first, we need to get a
>> solution which ensures that the transaction gets committed on all the
>> servers or is rolled back on all the foreign servers involved. AFAIR,
>> my patch did that. Once we have that kind of solution, we can think
>> about heuristics.
>
> I meant that we could determine it heuristically only when remote server
> crashed in 2nd phase of 2PC.
> For example, what does the local server returns to client when no one remote
> server returns OK to local server in 2nd phase of 2PC for more than
> statement_timeout seconds? Ok or error?
>
The local server doesn't wait for the completion of the second phase
to finish the currently running statement. Once all the foreign
servers have responded to PREPARE request in the first phase, the
local server responds to the client. Am I missing something?
>>
>> There will be many such XIDs. We don't want to dump so many things in
>> control file, esp. when that's not control data. System catalog is out
>> of question since a rollback of local transaction would make those
>> rows in the system catalog invisible. That's the reason, why I chose
>> to write the foreign prepared transactions to files rather than a
>> system catalog.
>>
>
> We can store the lowest in-doubt transaction id (say in-doubt XID) that
> needs to be resolved later into control file and the CLOG containing XID
> greater than in-doubt XID is never truncated.
> We need to try to solve such transaction only when in-doubt XID is not NULL.
>
IIRC, my patch takes care of this. If the oldest active transaction
happens to be later in the time line than the oldest in-doubt
transaction, it sets oldest active transaction id to that of the
oldest in-doubt transaction.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company