Stop hammering ir_translation id sequence #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the issue/feature this PR addresses: startup failures due to ir_translation_id_seq overflow (DataError)
Current behavior before PR: ir_translation_id_seq grows by big steps, can reach 2**31 in months
Desired behavior after PR is merged: ir_translation_id_seq grows only if new translations appear
(I have NOT signed Odoo CLA)
We've had some instances actually reaching the 2**31 limit, because
the temporary table used to prepare potential insertions used the same
id sequence as the main table, hence each insert in the temporary table
bumps the sequence.
Aggravations:
a safe range to reset the sequence.
Yes this probably means instances that restart too much, but that's another issue.
The whole system is questionable at best [1] but this fix should have no impact, and
improve a bit startup performance and PostgreSQL health. On the other hand, we can't
guarantee without a long analysis that's out of our scope that even changing
ir_translation to a bigint would have no impact, yet alone give this the full rewrite
it certainly deserves.
[1] for starters, why use the DB at all in preparation, and use a temporary table
that's logically tied to a specific connection ?