BDR and TX obeyance - Mailing list pgsql-general

From Riley Berton
Subject BDR and TX obeyance
Date
Msg-id rgsr3hxt8df.fsf@rberton.i-did-not-set--mail-host-address--so-tickle-me
Whole thread Raw
Responses Re: BDR and TX obeyance
Re: BDR and TX obeyance
Re: BDR and TX obeyance
Re: BDR and TX obeyance
List pgsql-general
I have been experimenting with BDR and have a question about how BDR
interacts with transactions.

bdrdemo=# create table thingy (id INT, value TEXT, PRIMARY KEY(id));
CREATE TABLE
bdrdemo=# create table tx_log(id INT, msg TEXT, PRIMARY KEY(id));
CREATE TABLE
bdrdemo=# insert into thingy (id, value) VALUES (1, 'insert from node1');
INSERT 0 1

From node1:

bdrdemo=# begin;
BEGIN
bdrdemo=# update thingy set value='update from node1' where id=1;
UPDATE 1
bdrdemo=# insert into tx_log (id, msg) values (1, 'tx log insert from node1');
INSERT 0 1
bdrdemo=# commit;
COMMIT

Simultaneously from node2:

bdrdemo=# begin;
BEGIN
bdrdemo=# update thingy set value='update from node2' where id=1;
UPDATE 1
bdrdemo=# insert into tx_log (id, msg) values (2, 'tx log insert from node2');
INSERT 0 1
bdrdemo=# commit;
COMMIT

...

bdrdemo=# select * from tx_log ;
 id |           msg
----+--------------------------
  1 | tx log insert from node1
  2 | tx log insert from node2
(2 rows)

bdrdemo=# select * from thingy ;
 id |       value
----+-------------------
  1 | update from node2
(1 row)

The conflict on the "thingy" table has resulted in node2 winning based
on last_update wins default resolution.  However, both inserts have
applied.  My expectation is that the entire TX applies or does not
apply.  This expectation is clearly wrong.

Question is: is there a way (via a custom conflict handler) to have the
TX obeyed?  I can't see a way to even implement a simple bank account
database that changes multiple tables in a single transaction without
having the data end up in an inconsistent state.  Am I missing something
obvious here?

Thanks in advance for any help.

riley

pgsql-general by date:

Previous
From: Wells Oliver
Date:
Subject: A unique pairs version of UNNEST() ?
Next
From: Andy Colson
Date:
Subject: Re: A unique pairs version of UNNEST() ?