Todd Lipcon has submitted this change and it was merged.

Change subject: KUDU-1775 (part 1). Reject CREATE TABLE with negative or 
too-high replication factors
......................................................................


KUDU-1775 (part 1). Reject CREATE TABLE with negative or too-high replication 
factors

This adds more master-side checking of the replication factor passed
from the client:

* must be non-negative. Previously passing a negative replication factor
  would result in infinite retries trying to assign replicas.

* put an upper bound of 7, configurable with a new unsafe flag. We
  haven't tested higher replication factors at all, and a
  well-intentioned user may try to set replication factor to a very high
  number to get a table replicated onto every server in their cluster.
  This is common practice in MPP RDBMS, but since we haven't tested it,
  we shouldn't allow it without making the user turn on
  --unlock_unsafe_flags.

Change-Id: I83fedc7cb9722c049c20eb7766605fbb2f966347
Reviewed-on: http://gerrit.cloudera.org:8080/5289
Reviewed-by: Adar Dembo <[email protected]>
Tested-by: Kudu Jenkins
---
M src/kudu/client/client-test.cc
M src/kudu/client/client.cc
M src/kudu/client/table_creator-internal.cc
M src/kudu/client/table_creator-internal.h
M src/kudu/master/catalog_manager.cc
M src/kudu/master/master.proto
6 files changed, 52 insertions(+), 35 deletions(-)

Approvals:
  Adar Dembo: Looks good to me, approved
  Kudu Jenkins: Verified



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

Gerrit-MessageType: merged
Gerrit-Change-Id: I83fedc7cb9722c049c20eb7766605fbb2f966347
Gerrit-PatchSet: 4
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <[email protected]>
Gerrit-Reviewer: Adar Dembo <[email protected]>
Gerrit-Reviewer: Dan Burkert <[email protected]>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Matthew Jacobs <[email protected]>
Gerrit-Reviewer: Todd Lipcon <[email protected]>
Gerrit-Reviewer: Will Berkeley <[email protected]>

Reply via email to