Fix llmeta schema change object leaks - #6155
Conversation
roborivers
left a comment
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Success ✓.
Regression testing: Success ✓.
The first 10 failing tests are:
consumer_non_atomic_default_consumer_generated **quarantined**
sc_downgrade [timeout] **quarantined**
truncatesc_offline_generated [timeout] **quarantined**
roborivers
left a comment
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Error ⚠.
Regression testing: Success ✓.
The first 10 failing tests are:
sc_truncate [db unavailable at finish]
consumer_non_atomic_default_consumer_generated **quarantined**
unifiedcancel **quarantined**
sc_downgrade [timeout] **quarantined**
osql_finalize_scs deleted the sc_list keyed by the schema change uuid, set only for TRANLEVEL_SOSQL; key it by the osql session uuid instead. Only kinds running through do_ddl() reach mark_schemachange_over_tran(), so stop persisting an sc seed for the others (sp, trigger, lua func) -- nothing ever removed it. Resumed sc lists no longer mark those kinds as resuming, as they have no persisted state to pick up. OSQL_FLAGS_SCDONE is set when a schema change is dispatched, before a downgrade can be seen by its async conversion, and was never cleared, so the abort path deleted the sc_list the new master needed to resume from. A failed multi-table resume dropped its ireq, orphaning the schema changes that had started and stranding the sc_list, and gave up on the remaining sc lists. Signed-off-by: Dorin Hogea <dhogea@bloomberg.net>
1f62618 to
08d371c
Compare
roborivers
left a comment
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Success ✓.
Regression testing: Success ✓.
The first 10 failing tests are:
consumer_non_atomic_default_consumer_generated **quarantined**
sc_downgrade [timeout] **quarantined**
reco-ddlk-sql [timeout] **quarantined**
2 participants
osql_finalize_scs deleted the sc_list keyed by the schema change uuid, set only for TRANLEVEL_SOSQL; key it by the osql session uuid instead.
Only kinds running through do_ddl() reach mark_schemachange_over_tran(), so stop persisting an sc seed for the others (sp, trigger, lua func) -- nothing ever removed it. Resumed sc lists no longer mark those kinds as resuming, as they have no persisted state to pick up.
OSQL_FLAGS_SCDONE is set when a schema change is dispatched, before a downgrade can be seen by its async conversion, and was never cleared, so the abort path deleted the sc_list the new master needed to resume from.
A failed multi-table resume dropped its ireq, orphaning the schema changes that had started and stranding the sc_list, and gave up on the remaining sc lists.
re: 185631797