Re: Problem with restoring database from a pg_dump generated script.
От | Tom Lane |
---|---|
Тема | Re: Problem with restoring database from a pg_dump generated script. |
Дата | |
Msg-id | 4679.989593728@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Problem with restoring database from a pg_dump generated script. ("Jerry Davis" <jdavis@teamdev.com>) |
Список | pgsql-bugs |
"Jerry Davis" <jdavis@teamdev.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
В списке pgsql-bugs по дате отправления: