Re: Problem with restoring database from a pg_dump generated script.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jerry Davis" <jdavis(at)teamdev(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, "Andrew Fritz" <afritz(at)teamdev(dot)com>
Subject: Re: Problem with restoring database from a pg_dump generated script.
Date: 2001-05-11 15:08:48
Message-ID: 4679.989593728@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Jerry Davis" <jdavis(at)teamdev(dot)com> writes:
> CREATE SEQUENCE login_primary_key_seq start 1 increment 1 maxvalue
> 2147483647 minvalue 1 cache 1 ;
> SELECT nextval ('login_primary_key_seq');

> Is there something missing from the original database that got
> dumped, or something I have to manually do to the dumped script
> that will allow a no-problem restore?

Hm. Apparently pg_dump should have restored this sequence with an
initial value of 9, not 1. Not sure why it didn't. If I try

create table foo (f1 serial);
insert into foo default values;
insert into foo default values;
insert into foo default values;

and then dump this in 7.0.*, I get

\connect - tgl
CREATE SEQUENCE "foo_f1_seq" start 3 increment 1 maxvalue 2147483647 minvalue 1 cache 1 ;
SELECT nextval ('"foo_f1_seq"');
CREATE TABLE "foo" (
"f1" int4 DEFAULT nextval('foo_f1_seq'::text) NOT NULL
);
COPY "foo" FROM stdin;
1
2
3
\.
CREATE UNIQUE INDEX "foo_f1_key" on "foo" using btree ( "f1" "int4_ops" );

which as you can see initializes the sequence to the right place (the
next nextval() will produce 4).

Can you recall anything about the history of your table that might have
caused the sequence to get reset?

Anyway, fixing the database state just requires issuing a setval() to
set the sequence to the desired place.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Patti Morgan 2001-05-11 15:20:21 RE: exists <==> not exists ???
Previous Message Tom Lane 2001-05-11 14:23:15 Re: Irix build failes (PSQL 7.1.1)