Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays - Mailing list pgsql-general

From John DeSoi
Subject Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays
Date
Msg-id 168F8EF9-301D-439E-A773-E6E20D33DBD8@pgedit.com
Whole thread Raw
In response to [GENERAL] pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays  (Toby Corkindale <toby.corkindale@strategicdata.com.au>)
Responses Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reportsunlikely, very large delays  (Toby Corkindale <toby.corkindale@strategicdata.com.au>)
List pgsql-general
> On Mar 22, 2017, at 8:06 PM, Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
>
> My best guess for what is going on is:
> - There has been no activity for hours or days, and so the oldest replayed
> transaction on the slave is genuinely quite old.
> - Something has happened on the master that causes its
> pg_current_xlog_location() to be updated, but not in a way that is sent to the
> slave until the end of a long-running transaction.
>
>
> Could anyone suggest how to do this in a manner that avoids the problem?

Are you using streaming replication or only WAL archiving? If you are not streaming the archive command does not send
thefile until it is full (16MB, if I recall correctly). To address this, you can change the archive_timeout setting to
ensurethe WAL file is sent at some interval even if it is not full. 

I use 'archive_timeout = 300' to send it every 5 minutes. If the lag is greater than 15 minutes, the alarm bells start
goingoff. 

John DeSoi, Ph.D.




pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] Run statements before pg_dump in same transaction?
Next
From: Toby Corkindale
Date:
Subject: Re: [GENERAL] pg_last_xact_replay_timestamp() sometimes reportsunlikely, very large delays