On Fri, Dec 2, 2011 at 4:48 AM, <hmf@alkheme.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: =A0 =A0 =A06317
> Logged by: =A0 =A0 =A0 =A0 =A0hua ming fei
> Email address: =A0 =A0 =A0hmf@alkheme.com
> PostgreSQL version: 9.0.1
> Operating system: =A0 Centos 5.5
> Description:
>
> use pg_dump when didn't close the application , weird things occured =
. the
> current value of one sequence is more slower than the max number of one
> primary key base on the sequence . So, I looked into the dump file , found
> command"
> SELECT pg_catalog.setval('attrnamemaster_attrnameid_seq', 3009, t=
rue);" to
> set sequence values number , but the import data, there are many lines wi=
th
> number larger than the sequence value :
> 3012 =A0 =A038 =A0 =A0 =A02147483647 =A0 =A0 =A0t =A0 =A0 =A0 10041 =A0 m=
aterial =A0 =A0 =A0 =A0material
> =A0 material =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01004.10041 =A0 =A0 =A04.1 =A0=
=A0 f
> 3013 =A0 =A038 =A0 =A0 =A02147483647 =A0 =A0 =A0t =A0 =A0 =A0 10042 =A0 d=
isable
> =A0 1004.10042 =A0 =A0 =A04.2 =A0 =A0 f
Without a reproducible test case, it's tough to see how anyone's going
to be able to fix any bug that may be lurking here. When you use
vague phrases like "when didn't close the application, weird things
occurred", it's kind of hard to figure out what exactly you did. If
you come up with a specific sequence of steps involving simple tools
like pg_dump and psql that produces a result you think is wrong,
someone here can probably (a) tell you whether the behavior is
intended, and (b) if not, fix it.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company