Notifications

31 views

Description

When an alter table transaction is triggered from the UI, for example from the Dictionary, and later gets cancelled by the user or a transaction quota rule, all the corresponding triggers and temporary tables are not cleaned from the DB.

The behavior is different when adding a new field to a table, in that case the transaction is not cancellable or does not get cancelled by the quota rule, so the issue does not occur.

Steps to Reproduce

1. Open a fairly large table (>1GB) in the dictionary.
2. Alter a filed in the table by increasing the column length.
3. Wait for the transaction to get cancelled or manually cancel it using 'cancel_my_transaction.do'.

After cancelling the transaction, the 'glide.db.online_alter' threads die off, but the triggers and table are left behind.

Workaround

This problem is under review and targeted to be fixed in a future release. To receive notifications when more information becomes available, subscribe to this Known Error article by clicking the Subscribe button at the top right of this form.

 


Related Problem: PRB1269518

Seen In

SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - ElasticSearch Integration - Madrid 2019 Q1
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Security Incident Response PA Content - New York 2019 Q3
SR - SIR - Security Incident Response UI Patch - London 2019 Q2 v.6.2.3
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - VR - Qualys - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3
SR - VR - Vulnerability Response PA Content - Madrid 2019 Q2

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-01-23 09:09:06
Published:2020-01-23