Re: tracking commit timestamps

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(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 20:36:48
Message-ID: 20141103203648.GU1791@alvin.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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.)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2014-11-03 20:39:26 Re: Maximum number of WAL files in the pg_xlog directory
Previous Message Alexey Vasiliev 2014-11-03 20:35:23 Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code

Browse pgsql-www by date

  From Date Subject
Next Message Peter Eisentraut 2014-11-03 21:26:11 Re: tracking commit timestamps
Previous Message Jim Nasby 2014-11-03 19:56:05 Re: tracking commit timestamps