Обсуждение: Update to 9.1.12
We are currently running PostgreSQL version 9.1.9-1~bpo60+1 (Debian Squeeze) and would like to update it to 9.1 9.1.12-0wheezy1.
But there is one serious issue about this update:
"
E.3.2. Changes
Fix VACUUM's tests to see whether it can update relfrozenxid (Andres Freund)
In some cases VACUUM (either manual or autovacuum) could incorrectly advance a table's relfrozenxid value, allowing tuples to escape freezing, causing those rows to become invisible once 2^31 transactions have elapsed. The probability of data loss is fairly low since multiple incorrect advancements would need to happen before actual loss occurs, but it's not zero. Users upgrading from releases 9.0.4 or 8.4.8 or earlier are not affected, but all later versions contain the bug.
The issue can be ameliorated by, after upgrading, vacuuming all tables in all databases while having vacuum_freeze_table_age set to zero. This will fix any latent corruption but will not be able to fix all pre-existing data errors. However, an installation can be presumed safe after performing this vacuuming if it has executed fewer than 2^31 update transactions in its lifetime (check this with SELECT txid_current() < 2^31). "
Please explain should I run VACUUM on all tables after the update if >
postgres=# SELECT txid_current() < 2^31;
?column?
----------
t
(1 row)
--
Best regards,
Viktor
Viktor wrote: > We are currently running PostgreSQL version 9.1.9-1~bpo60+1 (Debian Squeeze) and would like to update > it to 9.1 9.1.12-0wheezy1. > > But there is one serious issue about this update: > > " > E.3.2. Changes > > > > > Fix VACUUM's tests to see whether it can update relfrozenxid (Andres Freund) > > In some cases VACUUM (either manual or autovacuum) could incorrectly advance a table's relfrozenxid > value, allowing tuples to escape freezing, causing those rows to become invisible once 2^31 > transactions have elapsed. The probability of data loss is fairly low since multiple incorrect > advancements would need to happen before actual loss occurs, but it's not zero. Users upgrading from > releases 9.0.4 or 8.4.8 or earlier are not affected, but all later versions contain the bug. > > The issue can be ameliorated by, after upgrading, vacuuming all tables in all databases while having > vacuum_freeze_table_age <http://www.postgresql.org/docs/9.1/static/runtime-config-client.html#GUC- > VACUUM-FREEZE-TABLE-AGE> set to zero. This will fix any latent corruption but will not be able to fix > all pre-existing data errors. However, an installation can be presumed safe after performing this > vacuuming if it has executed fewer than 2^31 update transactions in its lifetime (check this with > SELECT txid_current() < 2^31). > > " > > Please explain should I run VACUUM on all tables after the update if > > > postgres=# SELECT txid_current() < 2^31; > ?column? > ---------- > t > (1 row) Yes. That's what the release notes say. One easy option is to run PGOPTIONS='-o vacuum_freeze_table_age=0' vacuumdb Yours, Laurenz Albe
Thank you for your reply.
Could you please explain what does this command exactly do ? Will it start VACUUM on all databases immidiatly ?
PGOPTIONS='-o vacuum_freeze_table_age=0' vacuumdb
Yes. That's what the release notes say.
One easy option is to run
PGOPTIONS='-o vacuum_freeze_table_age=0' vacuumdb
Yours,
Laurenz Albe
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Viktor Juhanson wrote: > Could you please explain what does this command exactly do ? Will it start VACUUM on all databases > immidiatly ? > PGOPTIONS='-o vacuum_freeze_table_age=0' vacuumdb Yes, it will. See the documentation of vacuumdb for what exactly it does. This is just an example of how you could run the VACUUM necessary after an upgrade to 9.1.12. There are many other ways to set vacuum_freeze_table_age, like in postgresql.conf. You could also connect with psql, use the SET command to set the parameter and run VACUUM manually. Yours, Laurenz Albe