hubert depesz lubaczewski wrote:
> INFO: vacuuming "pg_toast.pg_toast_106668498"
> vacuumdb: vacuuming of database "etsy_v2" failed: ERROR: could not access
> status of transaction 3429738606
> DETAIL: Could not open file "pg_clog/0CC6": No such file or directory.
>
> Interestingly.
>
> In old dir there is pg_clog directory with files:
> 0AC0 .. 0DAF (including 0CC6, size 262144)
> but new pg_clog has only:
> 0D2F .. 0DB0
>
> File content - nearly all files that exist in both places are the same, with
> exception of 2 newest ones in new datadir:
> 3c5122f3e80851735c19522065a2d12a 0DAF
> 8651fc2b9fa3d27cfb5b496165cead68 0DB0
>
> 0DB0 doesn't exist in old, and 0DAF has different md5sum:
> 7d48996c762d6a10f8eda88ae766c5dd
>
> one more thing. I did select count(*) from transactions and it worked.
Count(*) worked because it didn't access any of the long/toasted values.
> that's about it. I can probably copy over files from old datadir to new (in
> pg_clog/), and will be happy to do it, but I'll wait for your call - retry
> with
> copies files might destroy some evidence.
You can safely copy over any of the clog files that exist in the old
cluster but not in the new one, but another vacuum is likely to remove
those files again. :-(
This sure sounds like a variation on the pg_upgrade/toast bug we fixed
in 9.0.4:
http://wiki.postgresql.org/wiki/20110408pg_upgrade_fix
Can you get me the 9.0.X pg_class.relfrozenxid for the toast and heap
tables involved?
FYI, this is what pg_dump --binary-upgrade does to preserve the
relfrozenxids:
-- For binary upgrade, set heap's relfrozenxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '702'
WHERE oid = 'test'::pg_catalog.regclass;
-- For binary upgrade, set toast's relfrozenxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '702'
WHERE oid = '16434';
We also preserve the pg_class oids with:
-- For binary upgrade, must preserve pg_class oids
SELECT
binary_upgrade.set_next_heap_pg_class_oid('16431'::pg_catalog.oid);
SELECT
binary_upgrade.set_next_toast_pg_class_oid('16434'::pg_catalog.oid);
SELECT
binary_upgrade.set_next_index_pg_class_oid('16436'::pg_catalog.oid);
The question is whether this is working, and if not, why not?
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
