upgrade-master sets auto-increment counters for id fields incorrectly in postgresql

[szager]

When upgrading master database from 0.7.12 to 0.8.4p1, and creating the new database in postgresql, some of the tables have an 'id' field that uses an auto-increment counter to get a value for newly-added rows; something like this:

CREATE TABLE changes (

changeid PRIMARY KEY DEFAULT nextval('changes_changeid_seq'), ...

);

The problem is that the state of the counter is set incorrectly after the upgrade. For example, I upgraded a database that had 775 change records. The imported change records had the expected sequential changeid values 1-775, but the 'last_value' field of the changes_changeid_seq counter was 20, rather than the expected 775.

I have seen this in the changes.changeid field and the build.id field.

[dustin]

It would be great to have a test that can reproduce this. Off the top of my head, I can't see why this would happen.

[dustin]

On second thought, I totally see why it would happen -- since all of the inserts into changes specify a changeid, the sequence isn't consulted, nextval is never called, and .. it stays at 1.

So, this should have a testcase, and a solution. Both will need to be conditioned on Postgres, since this is a unique case.

[Dustin J. Mitchell]

Set postgres sequence values to allow inserts

This fixes #2119, where the explicit inserts done as Buildbot imports changes from pickles skip the call to nextval('changes_changeid_seq'), and thus leave that sequence value out of sync with the table contents.

Changeset: 0a3c28399e4c74e0d34cc33d8df66c435b991a28