On Thu, Oct 8, 2015 at 12:49 PM, Thomas Munro <thomas.munro@xxxxxxxxxxxxxxxx> wrote:
I got around to trying this on a recent rainy day:
https://github.com/macdice/check_pg_collations/blob/master/check_pg_collations
It needs Python and psycopg2. It notices when LC_COLLATE files' checksums change, and generates REINDEX commands on stdout. It seems to work OK on Debian, but I haven't tested much. Pull requests welcome :-) But I guess it would be much cooler as a pure plpgsql extension.
-- On Thu, Oct 8, 2015 at 5:52 AM, Peter Geoghegan
<peter.geoghegan86@xxxxxxxxx> wrote:
> On Wed, Oct 7, 2015 at 6:25 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> The only real way out of such a situation is to REINDEX affected indexes.
>> Refusing to start the server not only doesn't contribute to a solution,
>> but makes it impossible to fix manually.
>
> I agree that that would be almost as bad as carrying on, because there
> is no reason to think that the locale thing can easily be rolled back.
> That was my point, in fact.
I have contemplated a maintenance script that would track either the
md5 checksums of the /usr/lib/locale/*/LC_COLLATE files or the version
of installed locale packages and automatically reindex things when
they change (I guess after restarting the cluster to clear any glibc
caches that might be lurking in long running backends). Or at least
tell me that's needed. Obviously completely OS-specific...
I got around to trying this on a recent rainy day:
https://github.com/macdice/check_pg_collations/blob/master/check_pg_collations
It needs Python and psycopg2. It notices when LC_COLLATE files' checksums change, and generates REINDEX commands on stdout. It seems to work OK on Debian, but I haven't tested much. Pull requests welcome :-) But I guess it would be much cooler as a pure plpgsql extension.
Thomas Munro
http://www.enterprisedb.com
http://www.enterprisedb.com
