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

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

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pitrtools(at)lists(dot)commandprompt(dot)com
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Date: 2010-12-30 08:55:32
Message-ID: 4D1C4904.2000601@catalyst.net.nz (view raw or flat)
Thread:
Lists: pgsql-hackers
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:

primary:
$ grep archive_command postgresql.conf
  archive_command = 'rsync %p standby:/var/lib/postgresql/archive'
$ pgbench -c 4 -t 200000 bench
(wait for approx 10000 transactions)

standby:
$ psql -h primary -c "SELECT pg_start_backup('backup');"
$ rsync --exclude pg_xlog/\* --exclude postmaster.pid --delete 
--exclude=backup_label \
         primary:/var/lib/postgresql/8.3/main/* \
         /var/lib/postgresql/8.3/main
$ psql -h primary -c "SELECT pg_stop_backup();

$ grep restore_command recovery.conf
restore_command = '/usr/lib/postgresql/8.3/bin/pg_standby -t 
/tmp/trigger.5432 /var/lib/postgresql/archive %f %p %r'
$ /etc/init.d/postgresql-8.3 start
(wait for approx 140000 transactions)
$ touch /tmp/trigger.5432

Removing the offending

--delete --exclude=backup_label

options from the base backup step makes everything work properly again.

I'd be interested to know if the other folks getting these warnings were 
using unusual rsync options either during backup or for archiving.

regards

Mark

On 30/12/10 13:32, Mark Kirkwood wrote:
>
> I'm frankly puzzled about what Pitrtools is doing that is different - 
> I only noticed it using rsync compression (-z) and doing rsync backups 
> via pulling from the standby rather than pushing from the primary (I'm 
> in the process of trying these variations out in the bare bones case). 
> Just as I'm writing this I see Pitrtools rsync's pg_xlog - I wonder if 
> there is/are timing issues which mean that recovery might use some 
> (corrupted) logs from there before the (clean) archived ones arrive 
> (will check).
>


Attachment: cmd_standby.diff
Description: text/x-patch (1.3 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-12-30 11:39:13
Subject: Re: pg_streamrecv for 9.1?
Previous:From: Joel JacobsonDate: 2010-12-30 07:13:20
Subject: Re: pg_dump --split patch

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