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

Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: pitrtools(at)lists(dot)commandprompt(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Date: 2010-12-30 13:24:10
Message-ID: AANLkTi=7nfyL4VPJXfwM++fqFxVJCZr80xqyYQkcJuy-@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Dec 30, 2010 at 3:55 AM, Mark Kirkwood
<mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> wrote:
> Well, it is none of the things I considered.
>
> The problem seems to be due to use of "--delete" in the base backup rsync
> (see diff attached).  In fact I can now reproduce the uninitialized pages
> using the "bare bones" method:

Any time a relation is extended, we end up with a page of all zeros at
the end until the updated page is written out, which often doesn't
happen until the next checkpoint.  So it doesn't seem too mysterious
that you could end up with all zeroes pages on the standby initially,
but WAL replay ought to fix that.  I suppose the reason it isn't is
because you've excluded the backup label, so recovery will begin from
the wrong place.  Unless I'm missing something, that seems like a
really bad idea.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-12-30 13:31:17
Subject: Old git repo
Previous:From: Magnus HaganderDate: 2010-12-30 12:39:19
Subject: Re: pg_streamrecv for 9.1?

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