Re: eXtensible Transaction Manager API

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: eXtensible Transaction Manager API
Date: 2015-11-02 09:01:55
Message-ID: CANP8+jKn+m36b9Oi-VZyQZz-hHSbtHnvvcVFuV4qi0j0=HSmKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31 October 2015 at 10:22, 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

Very interesting work.

> xtm.patch patches PostgreSQL core by replacing direct calls of 7 TM
> functions with indirect calls and

At first I was concerned about recovery, but that looks to be covered.

PostgreSQL assumes that top-level xid commit is atomic, along with all of
its subtransactions. So the API having access to only Get/Set at the xid
level would not work. We would need TransactionIdSetTreeStatus() rather
than just SetStatus. GetStatus is not atomic.

> adding 3 addition events to transaction commit callbacks:
>

Those look uncontentious, so we should add those anyway in a sub-patch.

> 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.
>

That is most interesting part, so it needs to be published.

At present, I can't tell whether you need subtrans and multixact calls in
the API as well. I would imagine we probably do, though we might imagine an
implementation that didn't support those concepts.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-11-02 09:10:15 Re: onlyvalue aggregate (was: First Aggregate Funtion?)
Previous Message Dean Rasheed 2015-11-02 08:32:30 Re: onlyvalue aggregate (was: First Aggregate Funtion?)