Re: Transactions involving multiple postgres foreign servers, take 2 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Transactions involving multiple postgres foreign servers, take 2
Date
Msg-id 2ce2e9f8-d068-9069-4eff-6109753859b1@oss.nttdata.com
Whole thread Raw
In response to Re: Transactions involving multiple postgres foreign servers, take 2  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses RE: Transactions involving multiple postgres foreign servers, take 2  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers

On 2021/07/09 22:44, Masahiko Sawada wrote:
> On Fri, Jul 9, 2021 at 3:26 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>> As far as I read the code, keep using old API for foreign subtransaction doesn't
>> cause any actual bug. But it's just strange and half-baked to manage top and
>> sub transaction in the differenet layer and to use old and new API for them.
> 
> That's a valid concern. I'm really not sure what we should do here but
> I guess that even if we want to support subscriptions we have another
> API dedicated for subtransaction commit and rollback.
Ok, so if possible I will write POC patch for new API for foreign subtransactions
and consider whether it's enough simple that we can commit into core or not.


+#define FDWXACT_FLAG_PARALLEL_WORKER    0x02    /* is parallel worker? */

This implies that parallel workers may execute PREPARE TRANSACTION and
COMMIT/ROLLBACK PREPARED to the foreign server for atomic commit?
If so, what happens if the PREPARE TRANSACTION that one of
parallel workers issues fails? In this case, not only that parallel worker
but also other parallel workers and the leader should rollback the transaction
at all. That is, they should issue ROLLBACK PREPARED to the foreign servers.
This issue was already handled and addressed in the patches?

This seems not actual issue if only postgres_fdw is used. Because postgres_fdw
doesn't have IsForeignScanParallelSafe API. Right? But what about other FDW?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: unnesting multirange data types
Next
From: Tom Lane
Date:
Subject: Re: Replacing pg_depend PIN entries with a fixed range check