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
After a failed copy (due to duplicate primary keys), I've been encountering a hang. Sometimes it triggers an IOException from reading off the end of the metadata file, which appears to be caused by the numExistingNodeGroups in NodeBatchInsert::initGlobalStateInternal being much higher than it should be (I think as many as if the first copy had succeeded; I'd reproduced this with just a single tuple in the initial copy, and it went from 1 existing node group in the second failed copy, to 456 in the third one which threw the IOException). I'm not sure exactly where it's hanging though; interrupting the process in gdb just interrupts one thread in the task scheduler waiting on other threads to finish.
Initially reproduced in a custom branch, but reproduce-able on master (commit 68b5936).
The text was updated successfully, but these errors were encountered:
After a failed copy (due to duplicate primary keys), I've been encountering a hang. Sometimes it triggers an IOException from reading off the end of the metadata file, which appears to be caused by the
numExistingNodeGroups
inNodeBatchInsert::initGlobalStateInternal
being much higher than it should be (I think as many as if the first copy had succeeded; I'd reproduced this with just a single tuple in the initial copy, and it went from 1 existing node group in the second failed copy, to 456 in the third one which threw theIOException
). I'm not sure exactly where it's hanging though; interrupting the process in gdb just interrupts one thread in the task scheduler waiting on other threads to finish.Initially reproduced in a custom branch, but reproduce-able on master (commit 68b5936).
The text was updated successfully, but these errors were encountered: