Re: pg_upgrade does not upgrade pg_stat_statements properly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Cramer <davecramer(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Date: 2021-07-29 21:01:24
Message-ID: 915981.1627592484@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Cramer <davecramer(at)gmail(dot)com> writes:
> So back to the original motivation for bringing this up. Recall that a
> cluster was upgraded. Everything appeared to work fine, except that the
> definitions of the functions were slightly different enough to cause a
> fatal issue on restoring a dump from pg_dump.
> Since pg_upgrade is now part of the core project, we need to make sure this
> is not possible or be much more insistent that the user needs to upgrade
> any extensions that require it.

TBH, this seems like mostly the fault of the extension author.
The established design is that the SQL-level objects will be
carried forward verbatim by pg_upgrade. Therefore, any newer-version
shared library MUST be able to cope sanely with SQL objects from
some previous revision. The contrib modules provide multiple
examples of ways to do this.

If particular extension authors don't care to go to that much
trouble, it's on their heads to document that their extensions
are unsafe to pg_upgrade.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-07-29 21:30:53 Re: Doc: Fixed the result of the bit_count example
Previous Message Tom Lane 2021-07-29 20:54:27 Re: Case expression pushdown