于 2012/9/24 20:55, Bruce Momjian 写道:
On Sun, Sep 23, 2012 at 06:46:33PM -0400, Peter Eisentraut wrote:
On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
Ah yes, seems I used a wrong parameter. The --locale='zh_CN.utf8'
works. --locale='zh_CN.UTF8' also works. But still the question
于 2012/9/24 22:26, Bruce Momjian 写道:
On Mon, Sep 24, 2012 at 09:59:02PM +0800, Rural Hunter wrote:
于 2012/9/24 20:55, Bruce Momjian 写道:
On Sun, Sep 23, 2012 at 06:46:33PM -0400, Peter Eisentraut wrote:
On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
Ah yes, seems I used a wrong
于 2012/9/24 22:57, Bruce Momjian 写道:
On Mon, Sep 24, 2012 at 10:45:34PM +0800, Rural Hunter wrote:
If your operating system locale/encoding names changed after the initdb
of the old cluster, this would not be reflected in template0.
No. It's not changed. look at my system settings:
LANG
于 2012/9/25 11:00, Bruce Momjian 写道:
On Tue, Sep 25, 2012 at 08:41:19AM +0800, Rural Hunter wrote:
I think the problem is on the options when I installed pgsql(both
9.1 and 9.2)
Select the locale to be used by the new database cluster.
Locale
[1] [Default locale]
[2] C
[3] POSIX
[4
于2012年9月23日 20:33:48,Peter Eisentraut写到:
On Fri, 2012-09-21 at 17:16 +0800, Rural Hunter wrote:
If I run initdb with '-E zh_CN.utf8', it will tell me there
is no such charset in the system.
Because that is the name of a locale, not an encoding.
I found a workaround to run initdb
于 2012/9/19 7:22, Bruce Momjian 写道:
On Mon, Sep 17, 2012 at 05:07:23PM -0400, Bruce Momjian wrote:
# select * from pg_tables where tablename='sql_features';
schemaname | tablename | tableowner | tablespace |
hasindexes | hasrules | hastriggers
于2012年9月17日 1:17:46,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
OK, I see many new ALTER TABLE commands, but nothing that would cause a
difference in relation count.
Attached is a patch that will return the OID of the old/new mismatched
entries. Please
于2012年9月17日 9:48:58,Tom Lane写到:
Rural Hunter ruralhun...@gmail.com writes:
# select oid, * from pg_class WHERE reltoastrelid = 16439148;
oid| relname| relnamespace | reltype | reloftype |
relowner | relam | relfilenode | reltablespace | relpages | reltuples |
reltoastrelid
于2012年9月17日 12:32:36,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
I ran the pg_upgrade with the patch and found the problematic object
is a toast object.
OK
于2012年9月17日 12:47:11,Tom Lane写到:
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
Well, that's even stranger, because (1) information_schema.sql_features
ought to have a toast table in either version, and (2) neither pg_dump
nor pg_upgrade ought
10 matches
Mail list logo
