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

From Mark Kirkwood
Subject Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Date
Msg-id 4D1D075B.8070406@catalyst.net.nz
Whole thread Raw
In response to Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List 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



pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Next
From: Jim Nasby
Date:
Subject: Re: Sync Rep Design