On 11/3/14, 2:36 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/1/14, 8:41 AM, Petr Jelinek wrote:
Well this is not BDR specific thing, the idea is that with logical replication,
commit timestamp is not enough for conflict handling, you also need to have
additional info in order to identify some types of conflicts conflicts (local
update vs remote update for example). So the extradata field was meant as
something that could be used to add the additional info to the xid.
Related to this... is there any way to deal with 2 transactions that commit in
the same microsecond? It seems silly to try and handle that for every commit
since it should be quite rare, but perhaps we could store the LSN as extradata
if we detect a conflict?
Well, two things. One, LSN is 8 bytes and extradata (at least in this
patch when I last saw it) is only 4 bytes. But secondly and more
important is that detecting a conflict is done in node B *after* node A
has recorded the transaction's commit time; there is no way to know at
commit time that there is going to be a conflict caused by that
transaction in the future. (If there was a way to tell, you could just
as well not commit the transaction in the first place.)
I'm worried about 2 commits in the same microsecond on the same system, not on
2 different systems. Or, put another way, if we're going to expose this I think
it should also provide a guaranteed unique commit ordering for a single
cluster. Presumably, this shouldn't be that hard since we do know the exact
order in which things committed.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
