Re: [PROPOSAL] Backup and recovery of pg_statistic - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PROPOSAL] Backup and recovery of pg_statistic
Date
Msg-id 26804.1450885582@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PROPOSAL] Backup and recovery of pg_statistic  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
Responses Re: [PROPOSAL] Backup and recovery of pg_statistic  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgbench --latency-limit option
Next
From: Ildus Kurbangaliev
Date:
Subject: Re: Review: GiST support for UUIDs