Re: [PROPOSAL] Backup and recovery of pg_statistic
От | Dmitry Ivanov |
---|---|
Тема | Re: [PROPOSAL] Backup and recovery of pg_statistic |
Дата | |
Msg-id | 2854795.ZMV5h4SJdO@abook обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Backup and recovery of pg_statistic (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PROPOSAL] Backup and recovery of pg_statistic
|
Список | pgsql-hackers |
> 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. I'm sorry if my previous explanation was poor, this time I am going to be detailed. Suppose you want to upgrade from 9.4 to 9.6. In that case you would use the pg_upgrade utility provided by the release 9.6, which means that it's the pg_dump who would have to connect to the older instance and to prepare tuples to be inserted to the pg_statistic of the newer instance. The pg_dump utility would have to convert statistical data to the new format (for example, add placeholders for new columns), so generated INSERT statements would be fine provided that the pg_dump would be up-to-date. The documentation states that we should always run the pg_upgrade binary of the new server, not the old one [http://www.postgresql.org/docs/9.5/static/ pgupgrade.html, Usage, #9]. This means that the pg_upgrade will definitely use a fresh version of pg_dump utility that is aware of all possible pitfalls. Furthermore, each INSERT statement consists of textually-serialized columns of pg_statistic. Columns of 'anyarray' type are deserialized using the 'array_in' procedure which performs various sanity checks, including the element type check. Thus it is not possible to insert an anyarray object which will cause server death. -- Dmitry Ivanov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
В списке pgsql-hackers по дате отправления: