pg_dump / pg_restore 7.4.1的问题 [英] pg_dump/pg_restore problems with 7.4.1

查看:90
本文介绍了pg_dump / pg_restore 7.4.1的问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正试图通过

pg_dump / pg_restore从7.2迁移到7.4.1并且遇到了几个

问题:


1)表上的索引创建失败:


db = #CREATE UNIQUE INDEX person_info_username_ix ON

person_info使用btree(用户名);

错误:无法创建唯一索引

详细信息:表包含重复值。


当然,此索引存在于7.2数据库,所以它b / b似乎很奇怪它不可能重新创建。

此外,搜索重复值失败:


db =#select username,count(*)from person_info group

by username having count(*)> 1;

用户名| count

---------- + -------

(0行)


这是一个已知问题还是可能是一个错误?


2)导入时我得到:错误:无效内存

alloc请求大小1073741824。我将这个跟踪了

到一个带有一些非ASCII字符的行。

的类型是新数据库是LATIN1,这些是有效的LATIN1

字符。我用谷歌搜索了错误信息,发现

a bug报告听起来像是同样的问题:

http://www.mail-archive.com/pg****** .. ./msg07363.html


任何人都知道这是否被确认为错误,并且

是否正在调查?谢谢。


Ben

Ben


__________________________________

你是雅虎吗?

Yahoo! Hotjobs:输入签约奖金抽奖
http://hotjobs.sweepstakes.yahoo.com/signingbonus


---------------------------(播出结束)---- -----------------------

提示8:解释分析是你的朋友

解决方案

Ben Marklein< th ********** @ yahoo.com>写道:

我正试图通过
pg_dump / pg_restore从7.2迁移到7.4.1并遇到了几个问题:
1)索引在表上创建失败:
db = #CREATE UNIQUE INDEX person_info_username_ix ON
person_info使用btree(用户名);
错误:无法创建唯一索引
详细信息:表包含重复值。
当然,这个索引存在于7.2 DB中,所以它似乎很奇怪,它不应该重新创建。


这很有意思。这可能是一个字符串问题,在你当前的语言环境下等于
但是之前并不相等......但是为什么

不会是GROUP BY搜索找到那些重复的?我同意这个

听起来像个bug。你能提供测试数据来复制问题吗?

2)导入时我得到:错误:无效内存
分配请求大小1073741824。我用一些非ASCII字符跟踪了这一行。




我一直试图重现最近的这个报告,没有

成功。再一次,一个测试用例将具有很大的价值。


此外,您的平台究竟是什么,区域设置等等?您自己构建Postgres(使用什么配置设置)或者使用RPM

(谁)?


问候,tom车道


---------------------------(播出结束)----- ----------------------

提示2:您可以使用取消注册命令立即取消所有列表

(发送取消注册YourEmailAddressHere到 ma*******@postgresql.org


我可以把测试数据发给你,但它是保密的所以

我需要问你小心处理。可以

你联系我我的名单吗?我试图直接将

发送到您的帐户,但是被您的垃圾邮件反弹了

来自此帐户和另一个帐户的过滤器。


Ben


--- Tom Lane< tg *@sss.pgh.pa.us>写道:

Ben Marklein< th ********** @ yahoo.com>写道:

我正试图通过
pg_dump / pg_restore从7.2迁移到7.4.1并且遇到了一些


post_quotes>问题:


1)表上的索引创建失败:


db = #CREATE UNIQUE INDEX person_info_username_ix


ON

person_info使用btree(用户名);
错误:无法创建唯一索引
详细信息:表包含重复值。


当然,这个索引存在于7.2 DB中,所以它似乎很奇怪,它应该不可能


重新创建。

这很有趣。这可能是一个
字符串的问题,在你当前的语言环境下是相同的,但在......之前并不相等......但是为什么
不会是GROUP BY搜索找到那些重复的
呢?我同意这听起来像个bug。你能提供测试数据来重复问题吗?

2)导入时我得到:错误:无效内存
分配请求大小1073741824。我跟踪


向下

到一行包含一些非ASCII字符。



我一直试图重现最近的这个报告,没有成功。同样,测试用例具有很大的价值。

此外,您的平台究竟是什么,区域设置等等?你是自己构建Postgres(使用什么配置
设置)或使用RPM
(谁)?

问候,tom lane


__________________________________

你是Yahoo!?

Yahoo! Hotjobs:输入签约奖金抽奖
http://hotjobs.sweepstakes.yahoo.com/signingbonus


---------------------------(播出结束)---- -----------------------

提示9:如果您的

加入列的数据类型不匹配




希望你能解决这个问题。我们从未听说过类似的问题

升级---其他问题,是的,但不是这些。 :-)


----------------------------------- ----------------------------------------


Ben Marklein写道:

我正试图通过
pg_dump / pg_restore从7.2迁移到7.4.1并遇到了几个问题:

1)表上的索引创建失败:

db = #CREATE UNIQUE INDEX person_info_username_ix ON
person_info使用btree(用户名);
错误:无法创建唯一索引
详细信息:表包含重复的值。

当然,这个索引存在于7.2 DB中,所以它似乎很奇怪,它不应该重新创建。<此外,搜索重复值失败:

db =#选择用户名,来自person_info组的count(*)
按用户名计数(*)> 1;
用户名|计数
---------- + -------
(0行)

这是一个已知问题还是可能是一个错误?

2)导入时我得到:错误:无效内存
分配请求大小1073741824。我用一些非ASCII字符跟踪了这一行。新数据库的类型是LATIN1,这些是有效的LATIN1
字符。我搜索了错误消息并发现了一个错误报告听起来像是同样的问题:

http://www.mail-archive.com/pg******.../ msg07363 .html

任何人都知道这是否被证实是一个错误,并且
是否正在调查?谢谢。





__________________________________
雅虎你是谁!?
雅虎! Hotjobs:输入签约奖金抽奖
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------(广播结束)-------- -------------------
提示8:解释分析是你的朋友




-

Bruce Momjian | http://candle.pha.pa.us
pg *** @ candle.pha.pa.us | (610)359-1001

+如果你的生活是硬盘,|罗伯茨路13号

+基督可以成为你的备份。 |宾夕法尼亚州新城广场19073年


---------------------------(播出结束) - --------------------------

提示6:您是否搜索了我们的列表档案?

http://archives.postgresql.org


I''m trying to migrate from 7.2 to 7.4.1 via
pg_dump/pg_restore and have encountered a couple of
problems:

1) Index creation on a table fails:

db=# CREATE UNIQUE INDEX person_info_username_ix ON
person_info USING btree (username);
ERROR: could not create unique index
DETAIL: Table contains duplicated values.

Of course, this index existed in the 7.2 DB, so it
seems odd that it should not be possible to recreate.
Furthermore, a search for duplicate values fails:

db=# select username, count(*) from person_info group
by username having count(*) > 1;
username | count
----------+-------
(0 rows)

Is this a known issue or possibly a bug?

2) While importing I get: "ERROR: invalid memory
alloc request size 1073741824". I tracked this down
to a line with some non-ASCII characters. The type of
the new database is LATIN1, and these are valid LATIN1
characters. I googled for the error message and found
a bug report that sounds like the same problem:

http://www.mail-archive.com/pg******.../msg07363.html

Anyone know if this was confirmed as a bug, and
whether it''s being looked into? Thanks.

Ben
Ben

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

解决方案

Ben Marklein <th**********@yahoo.com> writes:

I''m trying to migrate from 7.2 to 7.4.1 via
pg_dump/pg_restore and have encountered a couple of
problems: 1) Index creation on a table fails: db=# CREATE UNIQUE INDEX person_info_username_ix ON
person_info USING btree (username);
ERROR: could not create unique index
DETAIL: Table contains duplicated values. Of course, this index existed in the 7.2 DB, so it
seems odd that it should not be possible to recreate.
That''s fairly interesting. It could be an issue of strings that are
equal under your current locale but weren''t equal before ... but why
wouldn''t the GROUP BY search find those duplicates too? I agree this
sounds like a bug. Can you provide test data to duplicate the problem?
2) While importing I get: "ERROR: invalid memory
alloc request size 1073741824". I tracked this down
to a line with some non-ASCII characters.



I have been trying to reproduce a recent report of this, without
success. Again, a test case would be of great value.

Also, what is your platform exactly, what locale settings, etc? Did
you build Postgres yourself (with what config settings) or use an RPM
(whose)?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)


I can send you the test data, but it''s confidential so
I''ll need to ask that you handle it carefully. Can
you contact me off-list about this? I tried to send
to your account directly but was bounced by your spam
filter from both this and another account.

Ben

--- Tom Lane <tg*@sss.pgh.pa.us> wrote:

Ben Marklein <th**********@yahoo.com> writes:

I''m trying to migrate from 7.2 to 7.4.1 via
pg_dump/pg_restore and have encountered a couple


of

problems:


1) Index creation on a table fails:


db=# CREATE UNIQUE INDEX person_info_username_ix


ON

person_info USING btree (username);
ERROR: could not create unique index
DETAIL: Table contains duplicated values.


Of course, this index existed in the 7.2 DB, so it
seems odd that it should not be possible to


recreate.

That''s fairly interesting. It could be an issue of
strings that are
equal under your current locale but weren''t equal
before ... but why
wouldn''t the GROUP BY search find those duplicates
too? I agree this
sounds like a bug. Can you provide test data to
duplicate the problem?

2) While importing I get: "ERROR: invalid memory
alloc request size 1073741824". I tracked this


down

to a line with some non-ASCII characters.



I have been trying to reproduce a recent report of
this, without
success. Again, a test case would be of great
value.

Also, what is your platform exactly, what locale
settings, etc? Did
you build Postgres yourself (with what config
settings) or use an RPM
(whose)?

regards, tom lane


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column''s datatypes do not match



Hope you got this fixed. We have never heard of similar problems with
upgrades --- other problems, yea, but not these. :-)

---------------------------------------------------------------------------

Ben Marklein wrote:

I''m trying to migrate from 7.2 to 7.4.1 via
pg_dump/pg_restore and have encountered a couple of
problems:

1) Index creation on a table fails:

db=# CREATE UNIQUE INDEX person_info_username_ix ON
person_info USING btree (username);
ERROR: could not create unique index
DETAIL: Table contains duplicated values.

Of course, this index existed in the 7.2 DB, so it
seems odd that it should not be possible to recreate.
Furthermore, a search for duplicate values fails:

db=# select username, count(*) from person_info group
by username having count(*) > 1;
username | count
----------+-------
(0 rows)

Is this a known issue or possibly a bug?

2) While importing I get: "ERROR: invalid memory
alloc request size 1073741824". I tracked this down
to a line with some non-ASCII characters. The type of
the new database is LATIN1, and these are valid LATIN1
characters. I googled for the error message and found
a bug report that sounds like the same problem:

http://www.mail-archive.com/pg******.../msg07363.html

Anyone know if this was confirmed as a bug, and
whether it''s being looked into? Thanks.

Ben
Ben

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend



--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


这篇关于pg_dump / pg_restore 7.4.1的问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆