Re: tracking commit timestamps - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: tracking commit timestamps
Date
Msg-id CA+U5nMKNMGQN2mwSPe=kgWd-ec+kC97ZNjCShUcbF9ehqVg0cw@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: tracking commit timestamps  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 11 November 2014 16:19, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-11-11 16:10:47 +0000, Simon Riggs wrote:
>> On 4 November 2014 08:23, Andres Freund <andres@2ndquadrant.com> wrote:
>>
>> >> 6) Shouldn't any value update of track_commit_timestamp be tracked in
>> >> XLogReportParameters? That's thinking about making the commit timestamp
>> >> available on standbys as well..
>> >
>> > Yes, it should.
>>
>> Agree committs should be able to run on standby, but it seems possible
>> to do that without it running on the master.
>
> I don't think that's realistic. It requires WAL to be written in some
> cases, so that's not going to work. I also don't think it's a
> particularly interesting ability?

OK, so we are saying commit timestamp will NOT be available on Standbys.

I'm fine with that, since data changes aren't generated there.


> So it works correctly. We're currently truncating the slru on startup
> when the guc is disabled which would cause problems WAL records coming
> in from the primary. I think the code also needs some TLC to correctly
> work after a failover.

OK

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Missing FIN_CRC32 calls in logical replication code
Next
From: Andres Freund
Date:
Subject: Re: tracking commit timestamps