Re: Fast default stuff versus pg_upgrade
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Date: 2018-06-19T16:08:41Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-06-19 11:51:16 -0400, Andrew Dunstan wrote:
>> Have we ever recommended use of pg_upgrade for some manual catalog fix after
>> release? I don't recall doing so. Certainly it hasn't been common.
> No, but why does it matter?
We absolutely have, as recently as last month:
* Fix incorrect volatility markings on a few built-in functions
(Thomas Munro, Tom Lane)
... can be fixed by manually updating these functions' pg_proc
entries, for example ALTER FUNCTION pg_catalog.query_to_xml(text,
boolean, boolean, text) VOLATILE. (Note that that will need to be
done in each database of the installation.) Another option is to
pg_upgrade the database to a version containing the corrected
initial data.
regards, tom lane
Commits
-
Allow for pg_upgrade of attributes with missing values
- 2448adf29c54 11.0 landed