Re: tracking commit timestamps - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: tracking commit timestamps
Date
Msg-id CA+U5nM+W8XB8b-MvddCsSprxkKq4L6RYqGV1CrjCDeZfd6EXSw@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: tracking commit timestamps
List pgsql-hackers
On 13 November 2014 21:24, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Nov 13, 2014 at 8:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> 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.
>
> Perhaps you could respond more specifically to concerns expressed
> upthread, like:
>
> http://www.postgresql.org/message-id/BLU436-SMTP28B68B9312CBE5D9125441DC870@phx.gbl
>
> I don't see that as a dumb argument on the face of it.

We have a clear "must have" argument for timestamps to support
replication conflicts.

Adding LSNs, when we already have a way to access them, is much more
of a nice to have. I don't really see it as a particularly nice to
have either, since the SLRU is in no way ordered.

Scope creep is a dangerous thing, so we shouldn't, and elsewhere
don't, collect up ideas like a bag of mixed sweets. It's easy to
overload things to the point where they don't fly at all. The whole
point of this is that we're building something faster than trigger
based systems.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS
Next
From: Simon Riggs
Date:
Subject: Re: using custom scan nodes to prototype parallel sequential scan