Re: pg_upgrade and toasted pg_largeobject
От | Robert Haas |
---|---|
Тема | Re: pg_upgrade and toasted pg_largeobject |
Дата | |
Msg-id | CA+TgmoYdyGV0U223hdNHD18mGN_5op+j6jSVeSpv+PO16f90qg@mail.gmail.com обсуждение исходный текст |
Ответ на | pg_upgrade and toasted pg_largeobject (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade and toasted pg_largeobject
|
Список | pgsql-hackers |
On Mon, May 2, 2016 at 12:30 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > A customer of ours was unable to pg_upgrade a database, with this error: > > old and new databases "postgres" have a mismatched number of relations > Failure, exiting > > After some research, it turned out that pg_largeobject had acquired a > toast table. After some more research, we determined that it was > because right after initdb of the old database (months or years prior) > they moved pg_largeobject to another, slower tablespace, because for > their case it is very bulky and not used as much as the other data. > (This requires restarting postmaster with the -O parameter). > > While I understand that manual system catalog modifications are frowned > upon, it seems to me that we should handle this better. The failure is > very confusing and hard to diagnose, and hard to fix also. I think that if you use -O, and it breaks something, you get to keep both pieces. pg_largeobject is a big problem, and we should replace it with something better. And maybe in the meantime we should support moving it to a different tablespace. But if it's not officially supported and you do it anyway, I don't think it's pg_upgrade's job to cope. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: