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.