Tom Lane <tgl@sss.pgh.pa.us> writes:
> If there is anybody still using Postgres on machines without wcstombs() or
> towlower(), and they have non-ASCII data indexed by pg_trgm, they'll need
> to REINDEX those indexes after pg_upgrade to 9.3, else searches may fail
> incorrectly. It seems likely that there are no such installations, though.
Those conditions seem just complex enough to require a test script that
will check that for you. What if we created a new binary responsible for
auto checking all those release-note items that are possible to machine
check, then issue a WARNING containing the URL to the release notes you
should be reading, and a SQL script (ala pg_upgrade) to run after
upgrade?
$ pg_checkupgrade -d "connection=string" > upgrade.sql
NOTICE: checking 9.3 upgrade release notes
WARNING: RN-93-0001 index idx_trgm_abc is not on-disk compatible with 9.3
WARNING: TN-93-0012 …
WARNING: This script is NOT comprehensive, read release notes at …
The target version would be hard coded on the binary itself for easier
maintaining of it, and that proposal includes a unique identifier for
any release note worthy warning that we know about, that would be
included in the output of the program.
I think most of the checks would only have to be SQL code, and some of
them should include running some binary code the server side. When
that's possible, we could maybe expose that binary code in a server side
extension so as to make the client side binary life's easier. That would
also be an excuse for the project to install some upgrade material on
the old server, which has been discussed in the past for preparing
pg_upgrade when we have a page format change.
What do you think?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
