Re: Transactions involving multiple postgres foreign servers

On Tue, Feb 17, 2015 at 2:56 PM, Ashutosh Bapat <
ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>
> 2. New catalog - This method takes out the need to have separate method
> for C1, C5 and even C2, also the synchronization will be taken care of by
> row locks, there will be no limit on the number of foreign transactions as
> well as the size of foreign prepared transaction information. But big
> problem with this approach is that, the changes to the catalogs are atomic
> with the local transaction. If a foreign prepared transaction can not be
> aborted while the local transaction is rolled back, that entry needs to
> retained. But since the local transaction is aborting the corresponding
> catalog entry would become invisible and thus unavailable to the resolver
> (alas! we do not have autonomous transaction support). We may be able to
> overcome this, by simulating autonomous transaction through a background
> worker (which can also act as a resolver). But the amount of communication
> and synchronization, might affect the performance.
>

For Rollback, why can't we do it in reverse way, first rollback
transaction in foreign servers and then rollback local transaction.

I think for Commit, it is essential that we first commit in local
server, so that we can resolve the transaction status of prepared
transactions on foreign servers after crash recovery. However
for Abort case, I think even if we don't Rollback in local server, it
can be deduced (any transaction which is not committed should be
Rolledback) during crash recovery for the matter of resolving
transaction status of prepared transaction.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com