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

From Robert Haas
Subject Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Date
Msg-id AANLkTi=7nfyL4VPJXfwM++fqFxVJCZr80xqyYQkcJuy-@mail.gmail.com
Whole thread Raw
In response to Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-hackers
On Thu, Dec 30, 2010 at 3:55 AM, Mark Kirkwood
<mark.kirkwood@catalyst.net.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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_streamrecv for 9.1?
Next
From: Magnus Hagander
Date:
Subject: Old git repo