Re: eXtensible Transaction Manager API

On 02.11.2015 12:01, Simon Riggs wrote:
>
> At first I was concerned about recovery, but that looks to be covered.
>
Yes, we have not considered all possible scenarios of working with
PostgreSQL.
We have tested work with different isolation levels: repeatable read and
read committed,
but we have not tested "select for update" and explicit locking.

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

XTM API has function SetTransactionStatus but it actually encapsulate
TransactionIdSetTreeStatus.

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

Will be available during this week.
>
> 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.

Postgres-XL doesn't support subtransactions. Neither did we at this moment.
Support of subtransactions will be our next step.