Re: [PROPOSAL] Backup and recovery of pg_statistic

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: [PROPOSAL] Backup and recovery of pg_statistic
Date: 2015-12-23 15:46:22
Message-ID: 26804.1450885582@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ildus Kurbangaliev 2015-12-23 16:10:53 Re: Review: GiST support for UUIDs
Previous Message Robert Haas 2015-12-23 15:44:39 Re: pgbench --latency-limit option