On Thu, Apr 13, 2017 at 11:48 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 4/12/17 22:56, Bruce Momjian wrote:
>> Is pg_upgrade the right place for an extension upgrade script?  When
>> pg_upgrade started creating an incremental-analyze script, people
>> thought it should be more generic so it was moved to vacuumdb
>> --analyze-in-stages.  Seems we should do the same thing for the
>> extension upgrade script.
> Yeah, many of the things that pg_upgrade would do or suggest after an
> upgrade could also apply to other upgrade methods, such as by logical
> replication.  So offering them separately would be good.

And in theory, extension upgrades could happen any time, not just when
there's a major version upgrade.  You could be using a
separately-bundled extension, or we could bump an extension version in
a minor release to fix some issue.

I think we should invent a clever name for a new utility, like
pg_maintain or something.  It could let you know about (and optionally
perform) a variety of optional maintenance tasks:

- upgrading extensions
- reindexing indexes for which the version has been bumped, like hash
indexes in v10
- reindexing or dropping indexes marked invalid that were left behind
by a CIC failure
- analyzing tables that lack (full?) statistics
- triggering heap scans to reclaim HEAP_MOVED_* bits, if we have that
kind of thing someday

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to