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)
Следующее
От: "Igor Neyman"
Дата:
Сообщение: Re: Preserving order through an inner join