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

Re: Keepalive for max_standby_delay

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Keepalive for max_standby_delay
Date: 2010-07-03 15:32:09
Message-ID: 11126.1278171129@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> It would seem logical to use the same logic for archive recovery as we 
> do for streaming replication, and only set XLogReceiptTime when you have 
> to wait for a WAL segment to arrive into the archive, ie. when 
> restore_command fails.

That would not do what you want at all in the case where you're
recovering from archive --- XLogReceiptTime would never advance
at all for the duration of the recovery.

It might be useful if you knew that it was a standby-with-log-shipping
situation, but we have no way to tell the difference.

The restore_command might know the difference, though.  Is it
worth modifying its API somehow so that the command could tell us
whether to advance XLogReceiptTime?  How would we do that?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-07-03 15:47:53
Subject: Re: reassign owned to change the ownership for op class and family
Previous:From: Simon RiggsDate: 2010-07-03 14:46:30
Subject: Re: Keeping separate WAL segments for each database

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