From: | Riley Berton <rberton(at)appnexus(dot)com> |
---|---|
To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: BDR and TX obeyance |
Date: | 2016-01-05 13:42:04 |
Message-ID: | rgs7fjota6v.fsf@rberton.i-did-not-set--mail-host-address--so-tickle-me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Edson Richter <edsonrichter(at)hotmail(dot)com> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
From | Date | Subject | |
---|---|---|---|
Next Message | George Woodring | 2016-01-05 14:04:13 | Re: SSL connection issue via perl |
Previous Message | Andreas Kretschmer | 2016-01-05 13:16:42 | Re: select and count efficiency (~35 mln rows) |