Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby and handling max_standby_delay

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby and handling max_standby_delay
Date: 2010-01-15 18:50:26
Message-ID: 4B50B8F2.20004@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs wrote:
> We need to calculate a more accurate time since WAL arrived to make
> max_standby_delay sensible in all cases. Difficult to know exactly when
> to record new timestamps for received WAL. So, proposal is...
> 
> if (Base time is earlier than WAL record time)
> 	standby_delay = WAL record time - Base time
> else
> 	standby_delay = now() - Base time
> 
> When standby_mode = off we record new base time when a new WAL file
> arrives.
> 
> When standby_mode = on we record new base time each time we do
> XLogWalRcvFlush(). We also record a new base time on first entry to the
> main for loop in XLogRecv(), i.e. each time we start writing a new burst
> of streamed WAL data.
> 
> So in either case, when we are waiting for new input we reset the timer
> as soon as new WAL is received. The resolution/accuracy of standby_delay
> will be no more than the time taken to replay a single file. This
> shouldn't matter, since sane settings of max_standby_delay are either 0
> or a number like 5-20 (seconds).

That would change the meaning of max_standby_delay. Currently, it's the
delay between *generating* and applying a WAL record, your proposal
would change it to mean delay between receiving and applying it. That
seems a lot less useful to me.

With the current definition, I would feel pretty comfortable setting it
to say 15 minutes, knowing that if the standby falls behind for any
reason, as soon as the connection is re-established or
archiving/restoring fixed, it will catch up quickly, blowing away any
read-only queries if required. With your new definition, the standby
would in the worst case pause for 15 minutes at every WAL file.

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

In response to

Responses

pgsql-hackers by date

Next:From: Markus WannerDate: 2010-01-15 18:51:36
Subject: Re: Testing with concurrent sessions
Previous:From: Greg SmithDate: 2010-01-15 18:44:18
Subject: Re: Streaming replication status

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group