Re: Keepalive for max_standby_delay

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jim Nasby <decibel(at)decibel(dot)org>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Keepalive for max_standby_delay
Date: 2010-05-18 21:08:13
Message-ID: 4BF301BD.6060102@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17/05/10 12:36, Jim Nasby wrote:
> On May 15, 2010, at 12:05 PM, Heikki Linnakangas wrote:
>> What exactly is the user trying to monitor? If it's "how far behind is
>> the standby", the difference between pg_current_xlog_insert_location()
>> in the master and pg_last_xlog_replay_location() in the standby seems
>> more robust and well-defined to me. It's a measure of XLOG location (ie.
>> bytes) instead of time, but time is a complicated concept.
>
> I can tell you that end users *will* want a time-based indication of how far behind we are. DBAs will understand "we're this many transactions behind", but managers and end users won't. Unless it's unreasonable to provide that info, we should do so.

No doubt about that, the problem is that it's hard to provide a reliable
time-based indication.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2010-05-18 21:12:52 Re: BYTEA / DBD::Pg change in 9.0 beta
Previous Message Jesper Krogh 2010-05-18 21:08:01 Re: pg_upgrade - link mode and transaction-wraparound data loss