Re: [PROPOSAL] Backup and recovery of pg_statistic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PROPOSAL] Backup and recovery of pg_statistic
Дата
Msg-id 26804.1450885582@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Backup and recovery of pg_statistic  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
Ответы Re: [PROPOSAL] Backup and recovery of pg_statistic  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
Список pgsql-hackers
Dmitry Ivanov <d.ivanov@postgrespro.ru> writes:
>> That concern is exactly the reason why we never did this originally.
>> In particular, emitting raw INSERTs into pg_statistic is just plain
>> foolish; we have changed the rowtype of pg_statistic in the past and
>> are likely to do so again.  At a minimum we would need such a facility
>> to be proof against addition of more statistic "slots" (more columns)
>> to pg_statistic.

> While this approach may indeed look dumb, it is intended to be used only in 
> conjunction with 'binary-upgrade' option, which effectively means that the 
> pg_dump-generated INSERT statement has to be compatible only with the release 
> that includes this very pg_dump version. Thus, there's no need for validation.

There's still the problem that it won't work across a major version
upgrade that makes any change whatsoever to the rowtype of pg_statistic.
That's a sufficient reason to reject it.

If the amount of infrastructure required were trivial, I'd probably be
okay with just putting it in as a kluge that pg_upgrade could use for
some version transitions and not others.  But your proposal seems quite
complicated, which makes me think we could solve the more general problem
for roughly comparable amounts of work.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pgbench --latency-limit option
Следующее
От: Ildus Kurbangaliev
Дата:
Сообщение: Re: Review: GiST support for UUIDs