Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-17 Thread Kevin Grittner
On Tuesday, November 17, 2015 12:43 AM, konstantin knizhnik wrote: > On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: >> If you are saying that DTM tries to roll back a transaction after >> any participating server has entered the RecordTransactionCommit() >>

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-17 Thread Alvaro Herrera
konstantin knizhnik wrote: > The transaction is normally committed in xlog, so that it can always be > recovered in case of node fault. > But before setting correspondent bit(s) in CLOG and releasing locks we first > contact arbiter to get global status of transaction. > If it is successfully

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-17 Thread konstantin knizhnik
On Nov 17, 2015, at 10:44 AM, Amit Kapila wrote: > > I think the general idea is that if Commit is WAL logged, then the > operation is considered to committed on local node and commit should > happen on any node, only once prepare from all nodes is successful. > And after that transaction is

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread Alvaro Herrera
Konstantin Knizhnik wrote: > But you may notice that original TransactionIdSetTreeStatus function is void > - it is not intended to return anything. > It is called in RecordTransactionCommit in critical section where it is not > expected that commit may fail. > But in case of DTM transaction may

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread Konstantin Knizhnik
On 11/16/2015 10:54 PM, Alvaro Herrera wrote: Konstantin Knizhnik wrote: But you may notice that original TransactionIdSetTreeStatus function is void - it is not intended to return anything. It is called in RecordTransactionCommit in critical section where it is not expected that commit may

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread Kevin Grittner
On Monday, November 16, 2015 2:47 AM, Konstantin Knizhnik wrote: > Some time ago at PgConn.Vienna we have proposed eXtensible >Transaction Manager API (XTM). > The idea is to be able to provide custom implementation of >transaction managers as standard

[HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread Konstantin Knizhnik
Hello, Some time ago at PgConn.Vienna we have proposed eXtensible Transaction Manager API (XTM). The idea is to be able to provide custom implementation of transaction managers as standard Postgres extensions, primary goal is implementation of distritibuted transaction manager. It should not

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread Atri Sharma
> I think the general idea is that if Commit is WAL logged, then the > operation is considered to committed on local node and commit should > happen on any node, only once prepare from all nodes is successful. > And after that transaction is not supposed to abort. But I think you are > trying to

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread Amit Kapila
On Tue, Nov 17, 2015 at 12:12 PM, konstantin knizhnik < k.knizh...@postgrespro.ru> wrote: > Thank you for your response. > > > On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: > > I'm not entirely clear on what you're saying here. I admit I've > not kept in close touch with the distributed

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

2015-11-16 Thread konstantin knizhnik
Thank you for your response. On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: > I'm not entirely clear on what you're saying here. I admit I've > not kept in close touch with the distributed processing discussions > lately -- is there a write-up and/or diagram to give an overview of > where