Re: tracking commit timestamps

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Steve Singer <steve(at)ssinger(dot)info>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, 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-13 13:18:22
Message-ID: CA+U5nMJKfOE1tLFUbg+n1a4qa_-vcFm-rFdk0gc1rZDgk3VsNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

On 9 November 2014 16:57, Steve Singer <steve(at)ssinger(dot)info> wrote:
> On 11/07/2014 07:07 PM, Petr Jelinek wrote:
>
>
>> The list of what is useful might be long, but we can't have everything
>> there as there are space constraints, and LSN is another 8 bytes and I still
>> want to have some bytes for storing the "origin" or whatever you want to
>> call it there, as that's the one I personally have biggest use-case for.
>> So this would be ~24bytes per txid already, hmm I wonder if we can pull
>> some tricks to lower that a bit.
>>
>
> The reason why Jim and myself are asking for the LSN and not just the
> timestamp is that I want to be able to order the transactions. Jim pointed
> out earlier in the thread that just ordering on timestamp allows for
> multiple transactions with the same timestamp.

I think we need to be clear about the role and function of components here.

Xid timestamps allow a replication system to do post-commit conflict
resolution based upon timestamp, i.e. last update wins. That is
potentially usable by BDR, Slony, xdb and anything else that wants
that.

Ordering transactions in LSN order is very precisly the remit of the
existing logical decoding API. Any user that wishes to see a commits
in sequence can do so using that API. BDR already does this, as do
other users of the decoding API. So Slony already has access to a
useful ordering if it wishes it. We do not need to anything *on this
patch* to enable LSNs for Slony or anyone else. I don't see any reason
to provide the same facility twice, in two different ways.

So in summary... the components are
* Commit LSN order is useful for applying changes - available by
logical decoding
* Commit timestamps and nodeid are useful for conflict resolution -
available from this patch

Both components have been designed in ways that allow multiple
replication systems to use these facilities.

So, -1 to including commit LSN in the SLRU alongside commit timestamp
and nodeid.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-11-13 13:33:44 Re: WAL format and API changes (9.5)
Previous Message Tomas Vondra 2014-11-13 13:11:51 Re: WIP: multivariate statistics / proof of concept

Browse pgsql-www by date

  From Date Subject
Next Message Petr Jelinek 2014-11-13 13:41:36 Re: tracking commit timestamps
Previous Message Petr Jelinek 2014-11-13 12:53:43 Re: tracking commit timestamps