Re: pg_upgrade bug found!
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Jeff Davis <pgsql@j-davis.com>, Alvaro Herrera <alvherre@commandprompt.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, RhodiumToad on IRC <andrew@tao11.riddles.org.uk>
Date: 2011-04-07T21:47:00Z
Lists: pgsql-hackers
Kevin Grittner wrote: > Bruce Momjian <bruce@momjian.us> wrote: > > > all we need to do is set those hint bits before the clog gets > > remove, so maybe just a SELECT * would do the trick! > > Does that mean that those experiencing the problem are failing to do > the vacuumdb run which is recommended in the pg_upgrade instructions? You know, I looked at that, but I don't think that is going to save me. :-( It says: Upgrade complete ---------------- | Optimizer statistics are not transferred by pg_upgrade | so consider running: | vacuumdb --all --analyze-only | on the newly-upgraded cluster. | Running this script will delete the old cluster's data files: | /usr/var/local/pgdev/pgfoundry/pg_migrator/pg_migrator/delete_old_cluster.sh We recommend 'vacuumdb --all --analyze-only' which I assume only samples random pages and does not set all the hint bits. In fact, you can't even analyze TOAST tables: test=> ANALYZE pg_toast.pg_toast_3596; WARNING: skipping "pg_toast_3596" --- cannot analyze non-tables or special system tables ANALYZE but you can SELECT from them: chunk_id | chunk_seq | chunk_data ----------+-----------+------------ (0 rows) Also, if we force VACUUM FREEZE on the toast tables we would have no need to advance their relfrozenxids because all the xids would be fixed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +