Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

On Thu, Dec 24, 2015 at 05:28:11PM +0300, Dmitry Ivanov wrote: > 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

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

Here's the patch with an 'array_elemtype' procedure which returns array's element type as an oid. It should apply to the commit fc995b. I wasn't sure if I shoud start a new thread. -- Dmitry Ivanov Postgres Professional: http://www.postgrespro.com Russian Postgres Companydiff --git

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

> 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

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

Dmitry Ivanov 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

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

> 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

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

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

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

Bruce Momjian writes: > On Fri, Nov 27, 2015 at 06:52:59PM +0300, Dmitry Ivanov wrote: >> 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

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

On 27 November 2015 at 15:52, Dmitry Ivanov wrote: Currently there is no way to backup 'pg_statistic' because columns of > 'anyarray' type cannot be reconstructed solely with their textual > representation. Meanwhile, all that is needed to solve this problem is a > small

[HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

Hi hackers, This is my proposal for 'pg_dump' utility enhancements which enable backup and recovery of statistical data stored in the 'pg_statistic' table. Statistical data is very valuable for the query planner, so support engineers have to manually generate it using ANALYZE whenever they