Re: Transactions involving multiple postgres foreign servers
От | Robert Haas |
---|---|
Тема | Re: Transactions involving multiple postgres foreign servers |
Дата | |
Msg-id | CA+TgmoaM+iH4r9yyPS3owYeFj_wgw-9ue-1dq=6i-WoDnSPyHQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Transactions involving multiple postgres foreign servers (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On Fri, Oct 21, 2016 at 1:38 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > Once we have that information, the foreign server can actively poll > the local server to get the status of transaction xid and resolves the > prepared transaction itself. It can go a step further and inform the > local server that it has resolved the transaction, so that the local > server can purge it from it's own state. It can remember the fate of > xid, which can be consulted by another foreign server if the local > server is down. If another transaction on the foreign server stumbles > on a transaction prepared (but not resolved) by the local server, > foreign server has two options - 1. consult the local server and > resolve 2. if the first options fails to get the status of xid or that > if that option is not workable, throw an error e.g. indoubt > transaction. There is probably more network traffic happening here. > Usually, the local server should be able to resolve the transaction > before any other transaction stumbles upon it. The overhead is > incurred only when necessary. Yes, something like this could be done. It's pretty complicated, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: