Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: pitrtools@lists.commandprompt.com
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-12-30T22:27:39Z
Lists: pgsql-hackers
On 31/12/10 11:11, Mark Kirkwood wrote:
>
> Yes, you (and Robert) are entirely correct, I was confused in my
> understanding of the "--delete --exclude=backup_label" and thought it
> to mean "exclude the backup label from the delete". Yeah the --delete
> is harmless, it is the exclude backup_label that is causing the problem.
>
> Note to all current Pitrtools users, this impacts you! We need to get
> a corrected version out soon I would think.
>
Also (not surprisingly) I can confirm that data corruption is possible:
1/ Perform approx 140000 transactions against the primary
2/ Cancel Pgbench
3/ Issue "SELECT pg_switch_xlog()" on primary
4/ Bring up standby after checking it has applied last log
The resulting primary and standby should be identical, but:
primary:
bench=# SELECT count(*) FROM branches;
count
-------
100
bench=# SELECT count(*) FROM accounts;
count
----------
10000000
standby:
bench=# SELECT count(*) FROM branches;
count
-------
132
bench=# SELECT count(*) FROM accounts;
count
---------
9998269
The other counts are the same. We have lost some accounts records, but
have gained duplicates in branches:
bench=# REINDEX TABLE branches;
ERROR: could not create unique index "branches_pkey"
DETAIL: Table contains duplicated values.
regards
Mark