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 | 4d8ef88b-0786-1b5f-8f04-5f69ea573b83@oss.nttdata.com 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 2020/09/10 10:13, tsunakawa.takay@fujitsu.com wrote: > Alexey-san, Sawada-san, > cc: Fujii-san, > > > From: Fujii Masao <masao.fujii@oss.nttdata.com> >> But if we >> implement 2PC as the improvement on FDW independently from PostgreSQL >> sharding, I think that it's necessary to support other FDW. And this is our >> direction, isn't it? > > I understand the same way as Fujii san. 2PC FDW is itself useful, so I think we should pursue the tidy FDW interface andgood performance withinn the FDW framework. "tidy" means that many other FDWs should be able to implement it. I guessXA/JTA is the only material we can use to consider whether the FDW interface is good. Originally start(), commit() and rollback() are supported as FDW interfaces. With his patch, prepare() is supported. Whatother interfaces need to be supported per XA/JTA? As far as I and Sawada-san discussed this upthread, to support MySQL, another type of start() would be necessary to issue"XA START id" command. end() might be also necessary to issue "XA END id", but that command can be issued via prepare()together with "XA PREPARE id". I'm not familiar with XA/JTA and XA transaction interfaces on other major DBMS. So I'd like to know what other interfacesare necessary additionally? > > >> Sawada-san's patch supports that case by implememnting some conponents >> for that also in PostgreSQL core. For example, with the patch, all the remote >> transactions that participate at the transaction are managed by PostgreSQL >> core instead of postgres_fdw layer. >> >> Therefore, at least regarding the difference 2), I think that Sawada-san's >> approach is better. Thought? > > I think so. Sawada-san's patch needs to address the design issues I posed before digging into the code for thorough review,though. > > BTW, is there something Sawada-san can take from Alexey-san's patch? I'm concerned about the performance for practicaluse. Do you two have differences in these points, for instance? IMO Sawada-san's version of 2PC is less performant, but it's because his patch provides more functionality. For example, with his patch, WAL is written to automatically complete the unresolve foreign transactions in the case of failure. OTOH, Alexey patch introduces no new WAL for 2PC. Of course, generating more WAL would cause more overhead. But if we need automatic resolution feature, it's inevitable to introduce new WAL whichever the patch we choose. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
pgsql-hackers by date: