Re: Transactions involving multiple postgres foreign servers
От | Kevin Grittner |
---|---|
Тема | Re: Transactions involving multiple postgres foreign servers |
Дата | |
Msg-id | 2011113877.3824142.1420723930838.JavaMail.yahoo@jws100155.mail.ne1.yahoo.com обсуждение исходный текст |
Ответ на | Re: Transactions involving multiple postgres foreign servers (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: Transactions involving multiple postgres foreign servers
|
Список | pgsql-hackers |
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > On Wed, Jan 7, 2015 at 9:50 PM, Kevin Grittner <kgrittn@ymail.com> wrote: >> Also, as previously mentioned, it must behave in some reasonable >> way if a database is not configured to support 2PC, especially >> since 2PC is off by default in PostgreSQL. > We can have a per foreign server option, which says whether the > corresponding server is able to participate in 2PC. A transaction > spanning multiple foreign server with at least one of them not > capable of participating in 2PC will be aborted. > > Will that work? > > In case a user flags a foreign server as capable to 2PC > incorrectly, I expect the corresponding FDW would raise error > (either because PREPARE fails or FDW doesn't handle that case) > and the transaction will be aborted anyway. That sounds like one way to handle it. I'm not clear on how you plan to determine whether 2PC is required for a transaction. (Apologies if it was previously mentioned and I've forgotten it.) I don't mean to suggest that these problems are insurmountable; I just think that people often underestimate the difficulty of writing a distributed transaction manager and don't always recognize the problems that it will cause if all of the failure modes are not considered and handled. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: