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

Refrain from preventing changes that are not really changes. #570

Merged
merged 1 commit into from
Jan 15, 2021

Conversation

DimCitus
Copy link
Collaborator

When a user runs the same command twice in a row, such as with the
following, make it so that the second time just works. It didn't because we
failed to observe that setting the candidate priority to zero could be a
non-changer if that's already the current value of the setting.

pg_autoctl set node candidate-priority --name node3 0

We could also skip the operation entirely, but this has two drawbacks:

  • the client implementation would then need to decide if it has to wait
    for the apply-settings steps to happen or immediately return,

  • more importantly, if there's a problem with synchronous_standby_names it
    might be good that setting a value to its current setting, thus applying
    no changes, forces a cache invalidation of the primary's setup.

Fixes #526

@DimCitus DimCitus added the bug Something isn't working label Jan 11, 2021
@DimCitus DimCitus added this to the Sprint 2020 W52 2021 W1 milestone Jan 11, 2021
@DimCitus DimCitus requested a review from JelteF January 11, 2021 14:29
@DimCitus DimCitus self-assigned this Jan 11, 2021
@DimCitus DimCitus added the Size: S Effort Estimate: Small label Jan 11, 2021
When a user runs the same command twice in a row, such as with the
following, make it so that the second time just works. It didn't because we
failed to observe that setting the candidate priority to zero could be a
non-changer if that's already the current value of the setting.

  pg_autoctl set node candidate-priority --name node3 0

We could also skip the operation entirely, but this has two drawbacks:

  - the client implementation would then need to decide if it has to wait
    for the apply-settings steps to happen or immediately return,

  - more importantly, if there's a problem with synchronous_standby_names it
    might be good that setting a value to its current setting, thus applying
	no changes, forces a cache invalidation of the primary's setup.
@DimCitus DimCitus force-pushed the fix/set-node-candidate-priority-idempotency branch from 16ad871 to 2f53389 Compare January 15, 2021 14:08
@DimCitus DimCitus merged commit a817326 into master Jan 15, 2021
@DimCitus DimCitus deleted the fix/set-node-candidate-priority-idempotency branch January 15, 2021 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Size: S Effort Estimate: Small
Projects
None yet
Development

Successfully merging this pull request may close these issues.

set node candidate-priority is not idempotent
2 participants