Re: eXtensible Transaction Manager API - Mailing list pgsql-hackers

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.