-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backup,import: count system table rows as rows #44965
Conversation
c1dc5bf
to
378ba4e
Compare
Previously we counted any KVs belonging to non-user tables as 'system records' rather than as 'rows' or 'index entries' the way they are counted for regular tables. This however meant that BACKUP or RESTORE would confusingly say that it had backed up 0 rows from a given system table when it in fact backed up its rows normally, unless one separately looked at the 'system record' count. Even if one does so, that is also confusing since it doesn't distinguish rows from index entries so the count does not match. Given that these counts are rolled up by table anyway the distinction gains us little. Release note (enterprise change): rows counts in BACKUP and RESTORE now include rows in system tables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, sorry for the delay!
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @pbardea)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status:
complete! 1 of 0 LGTMs obtained
TFTR! bors r+ |
Build failed (retrying...) |
44965: backup,import: count system table rows as rows r=dt a=dt Previously we counted any KVs belonging to non-user tables as 'system records' rather than as 'rows' or 'index entries' the way they are counted for regular tables. This however meant that BACKUP or RESTORE would confusingly say that it had backed up 0 rows from a given system table when it in fact backed up its rows normally, unless one separately looked at the 'system record' count. Even if one does so, that is also confusing since it doesn't distinguish rows from index entries so the count does not match. Given that these counts are rolled up by table anyway the distinction gains us little. Release note: none. 45010: storage/concurrency: move lock_table testdata to directory r=nvanbenschoten a=nvanbenschoten This creates room for new concurrency_manager testdata. There is a large diff, but it's just an outdent. We should probably get this in because #44975 so that we can put those new test cases in a new file. Co-authored-by: David Taylor <tinystatemachine@gmail.com> Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
Build succeeded |
Previously we counted any KVs belonging to non-user tables as 'system records'
rather than as 'rows' or 'index entries' the way they are counted for regular
tables. This however meant that BACKUP or RESTORE would confusingly say that
it had backed up 0 rows from a given system table when it in fact backed up
its rows normally, unless one separately looked at the 'system record' count.
Even if one does so, that is also confusing since it doesn't distinguish rows
from index entries so the count does not match. Given that these counts are
rolled up by table anyway the distinction gains us little.
Release note: none.