Edson Richter <edsonrichter@xxxxxxxxxxx> writes: > BTW, I'm also looking for a "synchronous multi-master" solution... If > you find one, please share :-) > The only solution I've found so far is a middleware that is close, the > C-Jdbc/Sequoia, which seems not being actively maintained for a while > now. See Postgres-R for sync multi-master. http://www.postgres-r.org/documentation/ Note that it is specifically geared towards low-latency environments and is likely not suitable for geo-distributed applications. It hasn't been touched in 4 years so likely not actively maintained. riley > > Regards, > > Edson > > Atenciosamente, > > Edson Carlos Ericksson Richter > > Em 04/01/2016 18:09, Riley Berton escreveu: >> 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 >> > > > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
