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