pg_upgrade
От | Brian Hirt |
---|---|
Тема | pg_upgrade |
Дата | |
Msg-id | A45C531F-F9A7-42FB-B228-651373617CFC@me.com обсуждение исходный текст |
Ответы |
Re: pg_upgrade
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-general |
I'm testing pg_upgrade out and ran into a couple of problems. First when I did pg_upgrade --check I got the tsearch2 tablespreventing the upgrade from happening: Database: testdatabase public.pg_ts_dict.dict_init public.pg_ts_dict.dict_lexize public.pg_ts_parser.prs_start public.pg_ts_parser.prs_nexttoken public.pg_ts_parser.prs_end public.pg_ts_parser.prs_headline public.pg_ts_parser.prs_lextype For testing, at this point I really didn't care about tsearch, so I simply dropped those tables so I could revisit them later-- however, I'm confused about these tables in general, both pg_catalog.pg_ts_parser and public.pg_ts_parser exist withdifferent, albeit similar, schemas. I think that the table in public is no longer used and was a remnant from pre-8.3when tsearch2 wasn't part of the distribution, can anyone confirm this? Anyway, after removing the tsearch tables, I did pg_upgrade --check again and it said the clusters were compatible. I proceededto run the upgrade command and it bombed out in the "Restoring user relation files" section. I've included someoutput below, any advice on what is going on? It seems something is messed up in either the check logic or actual migrationcode. root@ubuntu:~# /usr/pg-8.4/bin/oid2name All databases: Oid Database Name Tablespace ------------------------------------------- ... 11564 postgres pg_default ... root@ubuntu:~# /usr/pg-8.4/bin/oid2name -o 2683 From database "postgres": Filenode Table Name ---------------------------------------- 2683 pg_largeobject_loid_pn_index postgres@ubuntu:~$ /usr/pg-9.0/bin/pg_upgrade Performing Consistency Checks ----------------------------- Checking old data directory (/moby/pgdb-8.4) ok Checking old bin directory (/usr/pg-8.4/bin) ok Checking new data directory (/moby/pgdb-9.0) ok Checking new bin directory (/usr/pg-9.0/bin) ok Checking for reg* system oid user data types ok Checking for /contrib/isn with bigint-passing mismatch ok Checking for large objects ok Creating catalog dump ok Checking for presence of required libraries ok | If pg_upgrade fails after this point, you must | re-initdb the new cluster before continuing. | You will also need to remove the ".old" suffix | from /moby/pgdb-8.4/global/pg_control.old. Performing Migration -------------------- Adding ".old" suffix to old global/pg_control ok Analyzing all rows in the new cluster ok Freezing all rows on the new cluster ok Deleting new commit clogs ok Copying old commit clogs to new server ok Setting next transaction id for new cluster ok Resetting WAL archives ok Setting frozenxid counters in new cluster ok Creating databases in the new cluster ok Adding support functions to new cluster ok Restoring database schema to new cluster ok Removing support functions from new cluster ok Restoring user relation files /moby/pgdb-8.4/base/11564/2683 Could not find pg_toast.pg_toast_2147483647 in new cluster
В списке pgsql-general по дате отправления:
Предыдущее
От: Grzegorz JaśkiewiczДата:
Сообщение: Re: Deleting orphaned records (not exists is very slow)