Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
От | Mark Kirkwood |
---|---|
Тема | Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing |
Дата | |
Msg-id | 4D1D075B.8070406@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Список | 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 по дате отправления: