Re: Problems with pg_upgrade and extensions referencing catalog tables/views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Nasby, Jim" <nasbyj(at)amazon(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problems with pg_upgrade and extensions referencing catalog tables/views
Date: 2019-05-08 23:33:25
Message-ID: 9728.1557358405@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Nasby, Jim" <nasbyj(at)amazon(dot)com> writes:
> The problem is that pg_dump --binary-upgrade intentionally does not
> simply issue a `CREATE EXTENSION` command the way a normal dump does, so
> that it can control the OIDs that are assigned to objects[1].

That's not the only reason. The original concerns were about not
breaking the extension, in case the destination server had a different
version of the extension available. CREATE EXTENSION doesn't normally
guarantee that you get an exactly compatible extension version, which
is a good thing for regular pg_dump and restore but a bad thing
for binary upgrade.

I'm not really sure how to improve the situation you describe, but
"issue CREATE EXTENSION and pray" doesn't sound like a solution.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashwin Agrawal 2019-05-09 00:05:07 Re: Inconsistency between table am callback and table function names
Previous Message Peter Geoghegan 2019-05-08 22:37:50 Re: _bt_split(), and the risk of OOM before its critical section