Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, Rural Hunter <ruralhunter@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-09-24T14:38:51Z
Lists: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes: > On Mon, Sep 24, 2012 at 10:13:45AM -0400, Tom Lane wrote: >> FWIW, what I found out last time I touched this code is that on many >> systems setlocale doesn't bother to return a canonicalized spelling; >> it just gives back the string you gave it. It might be worth doing >> what Peter suggests, just to be consistent with what we are doing >> elsewhere, but I'm not sure how much it will help. > This comment in initdb.c doesn't sound hopeful: > * If successful, and canonname isn't NULL, a malloc'd copy of the locale's > * canonical name is stored there. This is especially useful for figuring out > * what locale name "" means (ie, the environment value). (Actually, > * it seems that on most implementations that's the only thing it's good for; > * we could wish that setlocale gave back a canonically spelled version of > * the locale name, but typically it doesn't.) Yeah, I wrote that. We can hope that the OP is running on a platform where setlocale does canonicalize the name, in which case doing the same thing in pg_upgrade that initdb does would fix his problem. But I'm not going to predict success. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Replace empty locale name with implied value in CREATE DATABASE and initdb.
- c7cea267de3c 9.2.0 cited