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

From Laurenz Albe
Subject Re: Transactions involving multiple postgres foreign servers, take 2
Date
Msg-id f44318e1ac5074268f0925e8c6e0619780a71fef.camel@cybertec.at
Whole thread Raw
In response to RE: Transactions involving multiple postgres foreign servers, take 2  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: Transactions involving multiple postgres foreign servers, take 2
List pgsql-hackers
On Fri, 2020-07-17 at 05:21 +0000, tsunakawa.takay@fujitsu.com wrote:
> From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> I have briefly checked the only oracle_fdw but in general I think that
> > if an existing FDW supports transaction begin, commit, and rollback,
> > these can be ported to new FDW transaction APIs easily.
> 
> Does oracle_fdw support begin, commit and rollback?

Yes.

> And most importantly, do other major DBMSs, including Oracle, provide the API for
> preparing a transaction?  In other words, will the FDWs other than postgres_fdw
> really be able to take advantage of the new FDW functions to join the 2PC processing?
> I think we need to confirm that there are concrete examples.

I bet they do.  There is even a standard for that.

I am not looking forward to adapting oracle_fdw, and I didn't read the patch.

But using distributed transactions is certainly a good thing if it is done right.

The trade off is the need for a transaction manager, and implementing that
correctly is a high price to pay.

Yours,
Laurenz Albe




pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: renaming configure.in to configure.ac
Next
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2