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).
>