Skip to content

Instantly share code, notes, and snippets.

@mikekaminskycc
Last active August 29, 2015 14:21
Show Gist options
  • Save mikekaminskycc/ef53acd2110687f01b01 to your computer and use it in GitHub Desktop.
Save mikekaminskycc/ef53acd2110687f01b01 to your computer and use it in GitHub Desktop.
Resetting the Audit Log Series

select count(*) from audit_log; 2652505123

From operational: select nextval('audit_log_id_seq'); 2752134460

If we exepect that the migration won't be run for two weeks, and we expect there to be 5 million rows added per day to the audit log between now and then, we get 14*5 = 70 million. 100 million to be safe. The sequence should be bumped forward 100 million from its current value of 2,752,134,460 giving us 2,852,134,460.

We are adding <300,000 IDs in our fixes, so this should be sufficient.



On average, we have a gap of about 20,000 IDs every weekday (about 7,000 on weekends). This gap means that we likely don't need to bump the ID forward at all...Should we, just to be safe?



From the logging server, we need to confirm that the sequence was reset on the same day (i.e., it was bumped back up to the number before the drop).

select id from audit_log_20130409 order by occurred_at desc limit 1; 553373632

select id from audit_log_20130521 order by occurred_at desc limit 1; 676407993

select id from audit_log_20130611 order by occurred_at desc limit 1; 735407034

select id from audit_log_20130625 order by occurred_at desc limit 1; 777476786

select id from audit_log_20140826 order by occurred_at desc limit 1; 1911234058

select id from audit_log_20140909 order by occurred_at desc limit 1; 1940192039

select id from audit_log_20140916 order by occurred_at desc limit 1; 1956379379

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment