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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
cmd_standby.diff text/x-patch 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

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