Re: eXtensible Transaction Manager API

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: eXtensible Transaction Manager API
Date: 2015-11-07 14:11:00
Message-ID: CAA4eK1LhNKG+mBjoWAXG2zbGYsm7Okc6ZAX8=2perFjjmSDsPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 31, 2015 at 2:52 PM, konstantin knizhnik <
k(dot)knizhnik(at)postgrespro(dot)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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-11-07 14:16:35 Re: Transactions involving multiple postgres foreign servers
Previous Message Peter Eisentraut 2015-11-07 12:25:27 Re: Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"