Re: [PROPOSAL] Backup and recovery of pg_statistic

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

> 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.

> And of course there was code to emit such a dump, producing one
> dump statement per occupied "slot" in pg_statistic plus one call to
> the other function per pg_statistic row.

> An API like this seems a good deal more future-proof than plain INSERTs.

This sounds really good, but I doubt that this is necessary if we're to just
preserve statistical data during an upgrade.

> Ideally, ordinary users
> could use this facility to transfer statistics for their own tables, just
> as they can use pg_dump ... but without adequate validity checking, it's
> way too much of a security hazard to allow that.

This could be implemented separately from the pg_dump if needed. The latter
proposal aims for the preservation of the statistical data during the database
upgrade, which is a rather important feature required by many DBAs. Of course,
it would be great if there was a way for a user to dump and restore stats for
his own tables on a whim, but, in my opinion, it is far less important.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2015-12-23 15:37:00 Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
Previous Message Fabien COELHO 2015-12-23 14:52:18 Re: pgbench --latency-limit option