Re: [PROPOSAL] Backup and recovery of pg_statistic

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PROPOSAL] Backup and recovery of pg_statistic
Дата
Msg-id 20151223001434.GA4222@momjian.us
обсуждение исходный текст
Ответ на [PROPOSAL] Backup and recovery of pg_statistic  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
Ответы Re: [PROPOSAL] Backup and recovery of pg_statistic  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Nov 27, 2015 at 06:52:59PM +0300, Dmitry Ivanov wrote:
> Proposed changes to pg_dump
> ===========================
> 
> Now that the approach has been developed, it may be applied to improve the 
> 'pg_dump' utility. Some minor code changes would make the 'pg_dump' emit 
> specially-formed recovery INSERTS for 'pg_statistic' in the 'binary-upgrade' 
> mode, thus allowing us to restore saved stats after an upgrade.

I think this is great.  My only question for the list is how much does
this dumping create new compatibility requirements between major
versions.  While pg_upgrade could disable it, pg_dump can't because it
doesn't know what PG version it is being loaded into.  Can we create a
format that is portable to all future PG versions, or at least detect
incompatibility?  I am thinking we would need some pg_statistic version
number in the dump data that can cause the data to be ignored.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: A Typo in regress/sql/privileges.sql
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Using quicksort for every external sort run