Re: tracking commit timestamps - Mailing list pgsql-hackers

From Andres Freund
Subject Re: tracking commit timestamps
Date
Msg-id 20141111171313.GK18565@alap3.anarazel.de
Whole thread Raw
In response to Re: tracking commit timestamps  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 2014-11-11 17:09:54 +0000, Simon Riggs wrote:
> 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.

Hm? They should be available - xact.c WAL replay will redo the setting
of the timestamps and explicitly overwritten timestamps will generate
their own WAL records. What I mean is just that you can't use commit
timestamps without also using it on the primary.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: tracking commit timestamps
Next
From: Tom Lane
Date:
Subject: Re: Column/type dependency recording inconsistencies