Open def- opened 2 years ago
@pkj415 Could this be related to https://github.com/yugabyte/yugabyte-db/issues/11628 ?
@def- This can happen with transactions disabled.
When transaction is enabled then transaction control the number of rows persisted.
Though with disabled transaction, each row gets inserted as single row transaction. If the copy gets cancelled abruptly then inflight writes which are already sent to docDB will get persisted. Another layer is that there is buffering in YSQL layer as well, if the buffer is not sent yet to docDB yet then that might get cleaned up as well and will be reflected as lost rows.
@sushantrmishra Alright, so this is expected behavior? Can close the bug in that case.
Jira Link: DB-578
Description
Not sure if this is important enough to warrant an issue, but this kind of missing flush could cause other missing data. I'm running current yugabyte-db master state (55c2d15d351d4e8315da2509ac5d0d827ffbfa0c). I created a large CSV file:
And tried reading it into a local RF3 database (macOS, M1):
After ~10 minutes I canceled the copy:
I would now expect 24622498 rows in t. When running
select count(*) from t;
immediately after the count is lower, after about a minute it reaches this number of rows. But if I restart the database before it reaches it, the last 498 rows seem to get lost permanently:I couldn't always reproduce this, probably depends on how much has to be flushed and timing, but I got it 2 times separately.