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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: More inaccurate results from numeric pow()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_upgrade and toasted pg_largeobject