Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-committers(at)postgresql(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
Date: 2013-04-10 18:46:17
Message-ID: 5165B379.3020201@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 04/08/2013 10:11 AM, Dimitri Fontaine wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2013-04-10 19:03:09 pgsql: Fix SIGUSR1 handling by unconnected bgworkers
Previous Message Tom Lane 2013-04-10 17:31:15 pgsql: Make contrib/pg_trgm also support regex searches with GiST index

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-04-10 19:09:30 Re: bgworker sigusr1 handler
Previous Message Andres Freund 2013-04-10 18:43:44 Re: Inconsistent DB data in Streaming Replication