Reschedule Feedback -> StateTransition background migration, attempt 2
What does this MR do and why?
After rescheduling the migration the second time in !108820 (merged) the migration stopped at 48% because we had a job that failed with PG::CardinalityViolation: ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time
This MR:
- Reschedules the migration
- Improves logging
Related to #387665 (closed)
Cause
ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time happens if you try to insert and update a record as a part of the same UPSERT operation which is... forbidden in PG but works in other databases according to https://github.com/rails/rails/issues/35519
PG gives the following explanation – https://github.com/postgres/postgres/blob/master/src/backend/executor/nodeModifyTable.c#L2522
Fix
In Fix cardinality error while upserting the ident... (!110921 - merged) we deduplicate identifiers based on their fingerprint so no duplicates are passed to UPSERT
Fix verification
With a little bit of "creative" monkeypatching and a brilliant suggestion from @dfrazao-gitlab I was able to test the fix on that particular batch in Draft: Test PG::CardinalityViolation fix (!110910 - closed)
The success is shown by the fact that !110910 (comment 1263447947) doesn't show failure
You can see the logs in https://ops.gitlab.net/gitlab-com/database-team/gitlab-com-database-testing/-/jobs/9154028/artifacts/browse/migration-testing if you have access
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.