Event Timeline
Comment Actions
actually again modified so we do the 3 update queries (160, 161) next to each other to avoid caveats [1].
Something like:
update revision set date_neg_utc_offset=false where date is not null and date_neg_utc_offset is null and id <= '\x0000000000000000000000000000000000000000' and id < '\x000346dc5d638865a00000000000000000000000'; update revision set committer_date_neg_utc_offset=false where committer_date is not null and committer_date_neg_utc_offset is null and id <= '\x0000000000000000000000000000000000000000' and id < '\x000346dc5d638865a00000000000000000000000'; update revision set extra_headers = ARRAY[]::bytea[][] where extra_headers is null and id <= '\x0000000000000000000000000000000000000000' and id < '\x000346dc5d638865a00000000000000000000000'; update revision set date_neg_utc_offset=false where date is not null and date_neg_utc_offset is null and id <= '\x000346dc5d638865a00000000000000000000000' and id < '\x00068db8bac710cb400000000000000000000000'; update revision set committer_date_neg_utc_offset=false where committer_date is not null and committer_date_neg_utc_offset is null and id <= '\x000346dc5d638865a00000000000000000000000' and id < '\x00068db8bac710cb400000000000000000000000'; update revision set extra_headers = ARRAY[]::bytea[][] where extra_headers is null and id <= '\x000346dc5d638865a00000000000000000000000' and id < '\x00068db8bac710cb400000000000000000000000'; update revision set date_neg_utc_offset=false where date is not null and date_neg_utc_offset is null and id <= '\x00068db8bac710cb400000000000000000000000' and id < '\x0009d495182a9930e00000000000000000000000'; update revision set committer_date_neg_utc_offset=false where committer_date is not null and committer_date_neg_utc_offset is null and id <= '\x00068db8bac710cb400000000000000000000000' and id < '\x0009d495182a9930e00000000000000000000000'; update revision set extra_headers = ARRAY[]::bytea[][] where extra_headers is null and id <= '\x00068db8bac710cb400000000000000000000000' and id < '\x0009d495182a9930e00000000000000000000000'; ...
[1] Thought process is to avoid the following:
- after each pass only of the each update queries on all revisions (which rewrote tuples), that will probably trigger a vacuum blocking the subsequent update... So doing that way, the vacuum should happen once. This seems to work as the first one is long but the 2 next update queries seems pretty fast (relying on pg_activity).
- splitting on range so the query is not ever lasting (meaning long-standing transaction) and create replication issues down the line...