Re: eXtensible Transaction Manager API

On Sat, Nov 7, 2015 at 10:23 PM, Konstantin Knizhnik <
k(dot)knizhnik(at)postgrespro(dot)ru> wrote:

>
> Lock manager is one of the tasks we are currently working on.
> There are still a lot of open questions:
> 1. Should distributed lock manager (DLM) do something else except
> detection of distributed deadlock?
>

I think so. Basically DLM should be responsible for maintaining
all the lock information which inturn means that any backend process
that needs to acquire/release lock needs to interact with DLM, without that
I don't think even global deadlock detection can work (to detect deadlocks
among all the nodes, it needs to know the lock info of all nodes).
This is somewhat inline with what currently we do during lock conflicts,
i.e if the backend incur a lock conflict and decides to sleep, before
sleeping it tries to detect an early deadlock, so if we make DLM responsible
for managing locks the same could be even achieved in distributed system.

> 2. Should DLM be part of XTM API or it should be separate API?
>

We might be able to do it either ways (make it part of XTM API or devise a
separate API). I think here more important point is to first get the high
level
design for Distributed Transactions (which primarily includes consistent
Commit/Rollback, snapshots, distributed lock manager (DLM) and recovery).

> 3. Should DLM be implemented by separate process or should it be part of
> arbiter (dtmd).
>

That's important decision. I think it will depend on which kind of design
we choose for distributed transaction manager (arbiter based solution or
non-arbiter based solution, something like tsDTM). I think DLM should be
separate, else arbiter will become hot-spot with respect to contention.

> 4. How to globally identify resource owners (0transactions) in global lock
> graph. In case of DTM we have global (shared) XIDs,
> and in tsDTM - global transactions IDs, assigned by application (which is
> not so clear how to retrieve).
> In other cases we may need to have local->global transaction id mapping,
> so looks like DLM should be part of DTM...
>
>
I think the DLM should in itself have all the necessary information to find
deadlocks or anything else required by locking system. For what kind of
cases, do you envision to identify global resource owners?
And I think if we require some interaction between DLM and DTM, then we
can implement the same, rather than making DLM part of DTM.

>
>
> 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)?
>
>
> In tsDTM approach two phase commit is performed by coordinator and
> currently is using standard PostgreSQL two phase commit:
>
>
> If commit at some of the nodes failed, coordinator should rollback
> prepared transaction at all nodes.
>
>
Can you please explain more about tsDTM approach, how timestamps
are used, what is exactly CSN (is it Commit Sequence Number) and
how it is used in prepare phase? IS CSN used as timestamp?
Is the coordinator also one of the PostgreSQL instance?

>
> 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.
>
>
> That is exactly what we are going to do - we are trying to integrate DTM
> with existed systems (pg_shard, postgres_fdw, BDR) and find out what is
> missed and should be added. In parallel we are trying to compare efficiency
> and scalability of different solutions.
>

One thing, I have noticed that in DTM approach, you seems to
be considering a centralized (Arbiter) transaction manager and
centralized Lock manager which seems to be workable approach,
but I think such an approach won't scale in write-heavy or mixed
read-write workload. Have you thought about distributing responsibility
of global transaction and lock management? I think such a system
might be somewhat difficult to design, but the scalability will be better.

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