Re: pg_upgrade libraries check

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade libraries check
Дата
Msg-id 26348.1338143572@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade libraries check  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_upgrade libraries check  (Andrew Dunstan <andrew@dunslane.net>)
Re: pg_upgrade libraries check  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: pg_upgrade libraries check  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> AIUI, for Tom's scheme to work pg_upgrade would need not to check 
> libraries that belonged to extension functions. Currently it simply 
> assumes that what is present in the old cluster is exactly what will be 
> needed in the new cluster. Tom's proposed scheme would completely 
> invalidate that assumption (which I would argue is already of doubtful 
> validity). Instead of explicitly trying to LOAD the libraries it would 
> have to rely on the "CREATE EXTENSION foo" failing, presumably at some 
> time before it would be too late to abort.

Well, the scheme I had in mind would require pg_upgrade to verify that
the new cluster contains an extension control file for each extension in
the old cluster (which is something it really oughta do anyway, if it
doesn't already).  After that, though, it ought not be looking at the
individual functions defined by an extension --- it is the extension's
business which libraries those are in.

The only reason for pg_upgrade to still look at probin at all would be
to cover C functions that weren't within extensions.  In the long run it
might be possible to consider those unsupported, or at least not common
enough to justify a safety check in pg_upgrade.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_upgrade libraries check
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_upgrade libraries check