Re: eXtensible Transaction Manager API
| От | Amit Kapila |
|---|---|
| Тема | Re: eXtensible Transaction Manager API |
| Дата | |
| Msg-id | CAA4eK1LhNKG+mBjoWAXG2zbGYsm7Okc6ZAX8=2perFjjmSDsPw@mail.gmail.com обсуждение исходный текст |
| Ответ на | eXtensible Transaction Manager API (konstantin knizhnik <k.knizhnik@postgrespro.ru>) |
| Ответы |
Re: eXtensible Transaction Manager API
|
| Список | pgsql-hackers |
On Sat, Oct 31, 2015 at 2:52 PM, konstantin knizhnik <k.knizhnik@postgrespro.ru> wrote:
Hi,
PostgresPro cluster team wants to announce proposal for eXtensible Transaction Manager API and reference implementation of distributed transaction manager (pg_dtm).
pg_dtm is just a standard PostgreSQL extension which should be installed in normal way.
Source of pg_dtm and PostgreSQL patches are available here: https://github.com/postgrespro/pg_dtm
WiKi page: https://wiki.postgresql.org/wiki/DTM
xtm.patch patches PostgreSQL core by replacing direct calls of 7 TM functions with indirect calls and adding 3 addition events to transaction commit callbacks:
postgres_fdw.patch patches postgres_fdw extension to work with DTM
We have also pgDTM implementation which is using timestamps (system time) as CSNs.
It is also based on the same XTM transaction API.
We will publish it later once we clarify problems with recovery and performance with this approach.
Also we have patch for pg_shard to work with DTM, which also will be published soon.
Today, while studying your proposal and related material, I noticed
that in both the approaches DTM and tsDTM, you are talking about
committing a transaction and acquiring the snapshot consistently, but
not touched upon the how the locks will be managed across nodes and
how deadlock detection across nodes will work. This will also be one
of the crucial points in selecting one of the approaches. Also I have
noticed that discussion about Rollback is not there, example how will
Rollback happen with API's provided in your second approach (tsDTM)?
Similarly, having some discussion on parts of recovery that could be affected
would be great.
I think in this patch, it is important to see the completeness of all the
API's that needs to be exposed for the implementation of distributed
transactions and the same is difficult to visualize without having complete
picture of all the components that has some interaction with the distributed
transaction system. On the other hand we can do it in incremental fashion
as and when more parts of the design are clear.
В списке pgsql-hackers по дате отправления: