On 04/08/2013 10:11 AM, Dimitri Fontaine wrote: > Tom Lane <t...@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.
given something like this also will have to be dealt with by pg_upgrade, why not fold it into that (like into -c) completly and recommend running that? on the flipside if people don't read the release notes they will also not run any kind of binary/script mentioned there... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
