-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-26797 HBase 1.x clients will choke on rep_barrier rows when scanning hbase 2.x meta #4161
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
Conversation
…nning hbase 2.x meta
@@ -220,6 +220,7 @@ private static Result getClosestRowOrBefore(final Table metaTable, final TableNa | |||
throws IOException { | |||
byte[] searchRow = HRegionInfo.createRegionName(userTableName, row, HConstants.NINES, false); | |||
Scan scan = Scan.createGetClosestRowOrBeforeReverseScan(searchRow); | |||
scan.addFamily(HConstants.CATALOG_FAMILY); |
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.
The real error comes from ConnectionManager, but I tried to audit all reads against meta table and this was the only other one (that I could find) which did not have a family specified. I figured I should add it while I'm here even if we haven't hit an issue with this yet.
🎊 +1 overall
This message was automatically generated. |
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, but please add comments adjacent to the added statements with at least a reference to the JIRA
Thanks for the review, I'll add that tomorrow. |
@apurtell done -- I'm assuming that's for added protection against a future regression, given the lack of a test. But correct me if I'm wrong, for my own edification. |
💔 -1 overall
This message was automatically generated. |
1a42a24
to
870b815
Compare
💔 -1 overall
This message was automatically generated. |
Correct, its so we know not to remove them without thought toward this issue since there isn't a test for it |
I found it really hard to add a test case for this. I think i'd need to modify meta to add a dummy extra CF and then put a bad row in there and validate that it gets ignored by these reads. That should be straightforward, but alters to meta are disallowed in a few places. I could probably add some sort of internal-only config to disable those checks for the purpose of test, or maybe a setter which sets a volatile value? It's hard to access them from the TestingUtility, but maybe doable. Let me know if you'd like me to go through those efforts to test this, but I think it might not be worth it?