Adar Dembo has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/8254 )

Change subject: catalog manager: fix DDL race
......................................................................


Patch Set 2:

(8 comments)

http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/catalog_manager.h
File src/kudu/master/catalog_manager.h:

http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/catalog_manager.h@726
PS2, Line 726:   Status FindTable(const TableIdentifierPB& table_identifier,
This doesn't exist anymore.


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/catalog_manager.cc
File src/kudu/master/catalog_manager.cc:

http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/catalog_manager.cc@1517
PS2, Line 1517:     *table_lock = TableMetadataLock(table_info->get(), 
lock_mode);
Maybe this would be simpler as:

  TableMetadataLock l(table_info->get(), lock_mode);
  if (<inverted>) {
    *table_lock = std::move(l);
    return Status::OK();
  }


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/catalog_manager.cc@1519
PS2, Line 1519:     // Ensure that between dropping the catalog manager lock 
and acquiring the
              :     // table metadata lock the table name has not been altered.
If this happens, why is it important to retry instead of returning "no table 
found"?

I can take my answer in the form of a code comment.


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/catalog_manager.cc@1522
PS2, Line 1522:         table_identifier.table_name() != 
table_lock->data().name()) {
Why is it sufficient to look at table_lock->data().name() and not also at 
table_names_map_?

I can take my answer in the form of a code comment.


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/master-test.cc
File src/kudu/master/master-test.cc:

http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/master-test.cc@1368
PS2, Line 1368:       req.mutable_table()->set_table_name(kTableName);
Nit: pedantry, but would you mind formatting these lines in the same way as in 
dropper? That is, maybe dropper should have an empty line between the 
declaration of req/resp/controller and their usage, or maybe its formatting 
style should be applied here.


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/master-test.cc@1371
PS2, Line 1371:       SCOPED_TRACE(SecureDebugString(resp));
Does this (and the same in dropper) actually have any effect? I thought it only 
does something when paired with ASSERT or EXPECT.


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/master/master-test.cc@1394
PS2, Line 1394:       ASSERT_OK(proxy_->DeleteTable(req, &resp, &controller));
Should be CHECK_OK, since it's a separate thread.


http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/util/cow_object.h
File src/kudu/util/cow_object.h:

http://gerrit.cloudera.org:8080/#/c/8254/2/src/kudu/util/cow_object.h@171
PS2, Line 171:    // An unlocked CowLock.
Might want to add that this is only useful for moving, since there's no 
explicit Lock() method.



--
To view, visit http://gerrit.cloudera.org:8080/8254
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I84ca3b207da28cd7dc43a077736da9b4e0ec6f37
Gerrit-Change-Number: 8254
Gerrit-PatchSet: 2
Gerrit-Owner: Dan Burkert <[email protected]>
Gerrit-Reviewer: Adar Dembo <[email protected]>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Tidy Bot
Gerrit-Comment-Date: Wed, 11 Oct 2017 18:31:31 +0000
Gerrit-HasComments: Yes

Reply via email to