You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In weird (rare) cases one may to explore that mon$attachments has record(s) related to some non-killed attachments, despite that we issue 'delete from mon$attachments' many times.
This attachment does not link to any running client (isql or anotherapp.), but is *does* occupy DB handle and prevent it from change to shutdown state.
It will be useful to add in mon$attachments table two fields with detalization about this "strange" record:
1) flag that this attach was notified that he must gone, and
2) timestamp of such notification.
PS.
Ticket has been created after discuss with dimitr.
The text was updated successfully, but these errors were encountered:
BTW: may be only one field is required, like "mon$delete_signal_timestamp" ?
If it is null than attachment was not notified, otherwise - signal was sent to him at corresponding time.
Submitted by: @pavel-zotov
In weird (rare) cases one may to explore that mon$attachments has record(s) related to some non-killed attachments, despite that we issue 'delete from mon$attachments' many times.
This attachment does not link to any running client (isql or anotherapp.), but is *does* occupy DB handle and prevent it from change to shutdown state.
It will be useful to add in mon$attachments table two fields with detalization about this "strange" record:
1) flag that this attach was notified that he must gone, and
2) timestamp of such notification.
PS.
Ticket has been created after discuss with dimitr.
The text was updated successfully, but these errors were encountered: