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

When replication factor > 1, all modifications are done via 2PC #5379

Merged
merged 1 commit into from
Oct 20, 2021

Conversation

onderkalaci
Copy link
Member

With Citus 9.0, we introduced citus.single_shard_commit_protocol which
defaults to 2PC.

With this commit, we prevent any user to set it to 1PC and drop support
for citus.single_shard_commit_protocol.

Although this might add some overhead for users, it is already the default
behaviour (so less likely) and marking placements as INVALID is much
worse.

DESCRIPTION: Drops GUC citus.single_shard_commit_protocol, defaults to 2PC

@onderkalaci onderkalaci force-pushed the drop_1pc_single_statement branch 4 times, most recently from 0bd8b34 to 611d7cb Compare October 15, 2021 11:20
@@ -51,6 +64,13 @@ SELECT * FROM the_table;
1 | 2 | 2
(1 row)

INSERT INTO the_replicated_table (a, b, z) VALUES (1, 2, 2);
Copy link
Member Author

Choose a reason for hiding this comment

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

This* is a side-effect that I didn't consider until I hit the error.

  • replication > 1 AND citus.writable_standby_coordinator TO ON now fails as we need to write 2PC record.

Copy link
Member

@marcocitus marcocitus Oct 18, 2021

Choose a reason for hiding this comment

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

I think that never really worked properly, since we also would not be able to write a shardstate record. A slightly better error message would be nice though.

Copy link
Member

@marcocitus marcocitus left a comment

Choose a reason for hiding this comment

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

I think this is fine, would be nice to fix the "cannot assign TransactionIds during recovery" error message.

@codecov
Copy link

codecov bot commented Oct 20, 2021

Codecov Report

Merging #5379 (39e0453) into master (a851211) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

❗ Current head 39e0453 differs from pull request most recent head 14e18af. Consider uploading reports for the commit 14e18af to get more accurate results

@@            Coverage Diff             @@
##           master    #5379      +/-   ##
==========================================
- Coverage   94.21%   94.18%   -0.03%     
==========================================
  Files         215      215              
  Lines       42818    42814       -4     
==========================================
- Hits        40339    40324      -15     
- Misses       2479     2490      +11     

@onderkalaci onderkalaci force-pushed the drop_1pc_single_statement branch 2 times, most recently from 14e18af to fa48ada Compare October 20, 2021 08:28
@onderkalaci onderkalaci enabled auto-merge (squash) October 20, 2021 08:30
With Citus 9.0, we introduced `citus.single_shard_commit_protocol` which
defaults to 2PC.

With this commit, we prevent any user to set it to 1PC and drop support
for `citus.single_shard_commit_protocol`.

Although this might add some overhead for users, it is already the default
behaviour (so less likely) and marking placements as INVALID is much
worse.
@onderkalaci onderkalaci merged commit 3f726c7 into master Oct 20, 2021
@onderkalaci onderkalaci deleted the drop_1pc_single_statement branch October 20, 2021 08:39
onderkalaci added a commit that referenced this pull request Jul 31, 2023
Prior to this commit, the code would skip processing the
errors happened for local commands.

Prior to #5379, it might
make sense to allow the execution continue. But, as of today,
if a modification fails on any placement, we can safely fail
the execution.
onderkalaci added a commit that referenced this pull request Jul 31, 2023
Prior to this commit, the code would skip processing the
errors happened for local commands.

Prior to #5379, it might
make sense to allow the execution continue. But, as of today,
if a modification fails on any placement, we can safely fail
the execution.
onderkalaci added a commit that referenced this pull request Aug 1, 2023
    Prior to this commit, the code would skip processing the
    errors happened for local commands.

    Prior to #5379, it might
    make sense to allow the execution continue. But, as of today,
    if a modification fails on any placement, we can safely fail
    the execution.
onderkalaci added a commit that referenced this pull request Aug 1, 2023
    Prior to this commit, the code would skip processing the
    errors happened for local commands.

    Prior to #5379, it might
    make sense to allow the execution continue. But, as of today,
    if a modification fails on any placement, we can safely fail
    the execution.
onderkalaci added a commit that referenced this pull request Aug 1, 2023
    Prior to this commit, the code would skip processing the
    errors happened for local commands.

    Prior to #5379, it might
    make sense to allow the execution continue. But, as of today,
    if a modification fails on any placement, we can safely fail
    the execution.

(cherry picked from commit b4008bc)
onderkalaci added a commit that referenced this pull request Aug 1, 2023
    Prior to this commit, the code would skip processing the
    errors happened for local commands.

    Prior to #5379, it might
    make sense to allow the execution continue. But, as of today,
    if a modification fails on any placement, we can safely fail
    the execution.

(cherry picked from commit b4008bc)
onderkalaci added a commit that referenced this pull request Aug 1, 2023
    Prior to this commit, the code would skip processing the
    errors happened for local commands.

    Prior to #5379, it might
    make sense to allow the execution continue. But, as of today,
    if a modification fails on any placement, we can safely fail
    the execution.

(cherry picked from commit b4008bc)
onderkalaci added a commit that referenced this pull request Aug 1, 2023
    Prior to this commit, the code would skip processing the
    errors happened for local commands.

    Prior to #5379, it might
    make sense to allow the execution continue. But, as of today,
    if a modification fails on any placement, we can safely fail
    the execution.

(cherry picked from commit b4008bc)
onderkalaci added a commit that referenced this pull request Aug 1, 2023
Prior to this commit, the code would skip processing the
errors happened for local commands.

Prior to #5379, it might
make sense to allow the execution continue. But, as of today,
if a modification fails on any placement, we can safely fail
the execution.

The first commit show the problem in action. The second commit
includes the fix and the test fixes.
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