views:

39

answers:

1

I recently created a SQL dump of a database behind a Django project, and after cleaning the SQL up a little bit was able to restore the DB and all of the data. The problem was the sequences were all mucked up. I tried adding a new user and generated the Python error IntegrityError: duplicate key violates unique constraint.

Naturally I figured my SQL dump didn't restart the sequence. But it did:

DROP SEQUENCE "auth_user_id_seq" CASCADE;
CREATE SEQUENCE "auth_user_id_seq" INCREMENT 1 START 446 MAXVALUE 9223372036854775807 MINVALUE 1 CACHE 1;
ALTER TABLE "auth_user_id_seq" OWNER TO "db_user";

I figured out that a repeated attempt at creating a user (or any new row in any table with existing data and such a sequence) allowed for successful object/row creation. That solved the pressing problem.

But given that the last user ID in that table was 446 - the same start value in the sequence creation above - it looks like Postgresql was simply trying to start creating rows with that key.

Does the SQL dump provide the wrong start key by 1? Or should I invoke some other command to start sequences after the given start ID? Keenly curious.

+3  A: 

The dump is fine, no problem. If your code (or default value for the column) uses nextval() to get the next value from the sequence, everything will be fine as well. Check your code and see what it does, what SQL is executed. With this information you can see why things are going wrong.

Good luck!

Frank Heikens
+1 Postgresql has no problem it this scenario. You can manually check that you last id in your table is not greater that the current sequence value.
leonbloy
I suppose that I was able to force this to 'clear' indicates it's a Django issue, not a Postgresql issue. (Adding add'l tags)
bennylope
I'm back to thinking there's an error on the Postgres side. After dumping the DB again and restoring, I noticed the same problems in Django. This time I tried selecting nextval from one sequence and got the current value of the max ID in that field. The subsequent call to nextval(), e.g. `SELECT nextval('sequence');` incremented the sequence. It's that initial call which isn't. If that's not an error in Postgres 8.1 then its certainly unexpected behavior to me! Referred by this answer http://stackoverflow.com/questions/3168187/django-orm-misreading-postgresql-sequences/3176972#3176972
bennylope
Why do you think it's an error in PostgreSQL? The dump is fine but we have no idea what kind of SLQ-query ends up in the above situation. When 446 is the last number, you have to use NEXTVAL, in the query or as default value. Version 8.1 will be EOL this year, you'd better migrate to a current version.
Frank Heikens
The only reason I thought it might be an error with Postgres, is that immediately after restoring the database from the dump, the value returned by NEXTVAL was equal to what I would have expected to be the CURRVAL - e.g. NEXTVAL returned the last ID present in the table, rather than the subsequent number. I haven't the expertise to say, "This is a bug" or where one might be, but it is - to me - inexplicable, to say the least!
bennylope