Investigate why dropping nonexistent constraint takes a long time
Details about this issue described here: !608 (merged) (MR doesn't fix this issue, it just discusses it).
Activity
mentioned in issue #215 (closed)
assigned to @Ickiewicz
added Doing label
I cannot repeat the issue, I broke hivemind sync on 15m of blocks, then restarted, and dropped all fks lasted 19ms. I suppose the observed issue was connected with haf#185 (closed), when during dropping indexes or foreign keys a trigger dropped shadow tables, now the issue is closed and shadow tables are not touched during editing indexes or Fks. However I reverted the changes regarding haf#185 (closed) in haf, and still I could not repeat the issue, so I'm not sure if the problem is already fixed or I don't know how to repeat it. What was the exact setup of the haf node ? Did only hivemind was syncing, or any other haf app also was running? The question is why accessing to a shadow table made a problem if app user (i suppose it was used to restart) is an owner of registered tables and their shadow tables ?
Edited by MarcinThis appears to be fixed, most likely by haf#185 (closed).
