Re: Tracking latest timeline in standby mode

On 08.02.2011 06:27, Robert Haas wrote:
> On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> I finally got around to look at this. I wrote a patch to validate that the
>>> TLI on xlog page header matches ThisTimeLineID during recovery, and noticed
>>> quickly in testing that it doesn't catch all the cases I'd like to catch
>>> :-(.
>>
>> The patch added into the CF hasn't solved this problem yet. Are you planning
>> to solve it in 9.1? Or are you planning to just commit the patch for 9.1, and
>> postpone the issue to 9.2 or later? I'm OK either way. Of course, the former
>> is quite better, though.
>>
>> Anyway, you have to add the documentation about this feature.
>
> This patch is erroneously marked Needs Review in the CommitFest
> application, but I think really it's Waiting on Author, and has been
> for a long time. I'm thinking we should push this out to 9.2.

I dropped the ball on this one, but now that we have pg_basebackup and
"pg_ctl promote" which make it easy to set up a standby and failover, I
think we should still do this in 9.1. Otherwise you need a restart to
have a 2nd standby server track the TLI change that failover causes.

I wanted to add those extra safeguards, and to support streaming
replication in addition to restoring from archive, but that's 9.2
material. However, the original patch
(http://archives.postgresql.org/message-id/4CC83A50.7070807@enterprisedb.com)
was non-intrusive and no-one objected. While the extra safeguards
would've been nice, this patch doesn't make the situation any worse than
it is already when you restart the standby.

Here's an updated version of that patch, now with a little bit of
documentation. Barring objections, I'll commit this.

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