On 04/08/2013 10:11 AM, Dimitri Fontaine wrote:
> 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.
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
