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

Hot Standby and handling max_standby_delay

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Hot Standby and handling max_standby_delay
Date: 2010-01-15 16:45:56
Message-ID: 1263573956.26654.36102.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
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).

Which means if we are busy we don't record many new times, whereas if we
are working in sporadic bursts we keep up with the latest time of
receipt. This also works when we are performing an archive_recovery for
an old backup.

Startup process will access base time each time it begins to wait and
calculate current standby_delay before comparing against
max_standby_delay.

Comments?

-- 
 Simon Riggs           www.2ndQuadrant.com


Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-15 16:47:44
Subject: Re: Streaming replication, loose ends
Previous:From: Heikki LinnakangasDate: 2010-01-15 16:42:27
Subject: Re: New XLOG record indicating WAL-skipping

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