Skip to content
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

Drop support for citus.multi_shard_commit_protocol #5380

Merged
merged 1 commit into from
Oct 21, 2021

Conversation

onderkalaci
Copy link
Member

@onderkalaci onderkalaci commented Oct 15, 2021

In the past, we allowed users to manually switch to 1PC
(e.g., one phase commit). However, with this commit, we
don't. All multi-shard modifications are done via 2PC.

DESCRIPTION: Drop support for citus.multi_shard_commit_protocol, always use 2PC

TODO:

  • Remove all references of citus.multi_shard_commit_protocol from the tests

COPY reference_table (a, b, z) FROM STDIN WITH CSV;
ERROR: cannot assign TransactionIds during recovery
COPY citus_local_table (a, b, z) FROM STDIN WITH CSV;
ERROR: cannot assign TransactionIds during recovery
Copy link
Member

@marcocitus marcocitus Oct 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be nice if we can give a better error message somehow, or is this the same error that PG gives?

Copy link
Member Author

@onderkalaci onderkalaci Oct 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the error PG gives.

There are some challenges to give proper errors and some input from you would be valuable:

  1. For replication factor == 1 tables, we use 2PC when it is a multi-shard command. But, we don't know (shouldn't know) whether the command is multi-shard until the executor. However, until we get the adaptive executor, PG already throws this error. So, the only place to give proper error is the planner. And, I hesitate to enforce this in the planner given that we might change it in the future?

  2. For COPY we always use 2PC, so can give a better error. But we do that even for single shard COPY commands. Do you think would that break some users?

2.2) For copy on Citus local tables, we trigger 2PC as for all other COPY commands. Maybe we can add a special case for Citus local tables?

@onderkalaci onderkalaci force-pushed the drop_1pc_single_statement branch 4 times, most recently from fa48ada to 64980c1 Compare October 20, 2021 08:33
Base automatically changed from drop_1pc_single_statement to master October 20, 2021 08:39
5 | 6 | 7
(2 rows)

ERROR: cannot assign TransactionIds during recovery
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to fix this error?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see #5380 (comment)

@@ -1499,6 +1475,22 @@ ReadOnlyTask(TaskType taskType)
}


bool
TaskListCannotBeExecutedInTransaction(List *taskList)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing function comment

In the past, we allowed users to manually switch to 1PC
(e.g., one phase commit). However, with this commit, we
don't. All multi-shard modifications are done via 2PC.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants