During the update from LimeSurvey 6.x to 7.0 it seems the tables lime_survey_123456 (we think this is what they were called before) have been renamed to lime_responses_123456 . Unfortunately this did not migrate the lime_survey_123456_id_seq sequence value to lime_responses_123456_seq_id, thus causing LimeSurvey to try to save new responses at ID 1, then 2, then 3 and so on although those ID slots are already filled.

So the easiest path out of this is setting the _seq_id to the highest ID of the corresponding table. The idiomatic PostgreSQL for this would be:

ALTER SEQUENCE lime_responses_123456_seq_id RESTART WITH 235;

This requires calculating the next free ID beforehand and would probably need to be wrapped in a lock to guarantee no insertions in the table between reading the next free ID and altering the sequence.

The other solution could be to use an "all in one" query like:

SELECT setval('lime_responses_123456_id_seq'::regclass, (SELECT MAX(ID) FROM lime_responses_123456));

setval has no concurrency guarantees though so it should probably only be run in this form in an environment with exclusive access, for example in a database migration.

I am also not sure if other tables might be affected by this issue, I hope the core developers can assess this.

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=40128

Fixed in Release 7.0.9+260812

Fixed in Release 7.0.9+260812