From: Simon Riggs on 15 Jan 2010 11:45 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: [HACKERS] ECPG documentation patch Next: Hot Standby and handling max_standby_delay |