Re: eXtensible Transaction Manager API
От | Simon Riggs |
---|---|
Тема | Re: eXtensible Transaction Manager API |
Дата | |
Msg-id | CANP8+jLbh-fnTkphBEccxKjG-TRgvO04RBQJSr-+8azez1C2rw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: eXtensible Transaction Manager API (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Список | pgsql-hackers |
On 7 November 2015 at 16:53, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
--
On 11/07/2015 05:11 PM, Amit Kapila wrote:Today, while studying your proposal and related material, I noticedthat in both the approaches DTM and tsDTM, you are talking aboutcommitting a transaction and acquiring the snapshot consistently, butnot touched upon the how the locks will be managed across nodes andhow deadlock detection across nodes will work. This will also be oneof the crucial points in selecting one of the approaches.
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?
2. Should DLM be part of XTM API or it should be separate API?
3. Should DLM be implemented by separate process or should it be part of arbiter (dtmd).
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...
Yes, we need a Distributed Lock Manager, but I think its a separate thing from the DTM.
(I'm loath to use the phase DLM, which was used within Oracle Parallel server for a buffer lock manager, which is not what is being discussed).
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: