| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
| Subject: | Re: tracking commit timestamps |
| Date: | 2014-11-03 19:56:05 |
| Message-ID: | 5457DDD5.9010105@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-www |
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?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2014-11-03 19:57:46 | Re: Let's drop two obsolete features which are bear-traps for novices |
| Previous Message | Peter Eisentraut | 2014-11-03 19:39:30 | Re: how to handle missing "prove" |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2014-11-03 20:36:48 | Re: tracking commit timestamps |
| Previous Message | Magnus Hagander | 2014-11-03 19:51:39 | Re: Can we put the docs for the current JDBC driver online? |