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