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()
>>
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
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
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
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
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
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
> 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
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
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
10 matches
Mail list logo