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

Fix unexpected behavior when turning appendonly on and off within a transaction #826

Merged
merged 3 commits into from
Jul 27, 2024

Conversation

enjoy-binbin
Copy link
Member

@enjoy-binbin enjoy-binbin commented Jul 24, 2024

If we do config set appendonly yes and config set appendonly no
in a multi, there are some unexpected behavior.

When doing appendonly yes, we will schedule a AOFRW, and when we
are doding appendonly no, we will call stopAppendOnly to stop it.
In stopAppendOnly, the aof_fd is -1 since the aof is not start yet
and the fsync and close will take the -1 and call it, so they will
all fail with EBADF. And stopAppendOnly will emit a server log, the
close(-1) should be no problem but it is still an undefined behavior.

This PR also adds a log Background append only file rewriting scheduled.
to bgrewriteaofCommand when it was scheduled. And adds a log in
stopAppendOnly when a scheduled AOF is canceled, it will print
AOF was disabled but there is a scheduled AOF background, cancel it.

…ransaction

If we do `config set appendonly yes` and `config set appendonly no`
in a multi, there are some unexpected behavior.

When doing appendonly yes, we will schedule a AOFRW, and when we
are doding appendonly no, we will call stopAppendOnly to stop it.
In stopAppendOnly, the aof_fd is -1 since the aof is not start yet
and the fsync and close will take the -1 and call it.

Signed-off-by: Binbin <[email protected]>
@enjoy-binbin enjoy-binbin requested a review from zuiderkwast July 24, 2024 15:59
Copy link

codecov bot commented Jul 24, 2024

Codecov Report

Attention: Patch coverage is 90.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 70.38%. Comparing base (3cca268) to head (358a374).
Report is 3 commits behind head on unstable.

Additional details and impacted files
@@             Coverage Diff              @@
##           unstable     #826      +/-   ##
============================================
+ Coverage     70.35%   70.38%   +0.02%     
============================================
  Files           112      112              
  Lines         61310    61322      +12     
============================================
+ Hits          43136    43160      +24     
+ Misses        18174    18162      -12     
Files Coverage Δ
src/aof.c 80.05% <90.00%> (+0.05%) ⬆️

... and 16 files with indirect coverage changes

Copy link
Contributor

@zuiderkwast zuiderkwast left a comment

Choose a reason for hiding this comment

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

Looks like a good fix. I don't understand the exact impact.

src/aof.c Show resolved Hide resolved
tests/integration/aof.tcl Outdated Show resolved Hide resolved
tests/integration/aof.tcl Show resolved Hide resolved
src/aof.c Show resolved Hide resolved
Signed-off-by: Binbin <[email protected]>
Co-authored-by: Viktor Söderqvist <[email protected]>
Signed-off-by: Binbin <[email protected]>
@enjoy-binbin enjoy-binbin merged commit e32518d into valkey-io:unstable Jul 27, 2024
44 checks passed
@enjoy-binbin enjoy-binbin deleted the aof_fd branch July 27, 2024 11:07
mapleFU pushed a commit to mapleFU/valkey that referenced this pull request Aug 22, 2024
…ransaction (valkey-io#826)

If we do `config set appendonly yes` and `config set appendonly no`
in a multi, there are some unexpected behavior.

When doing appendonly yes, we will schedule a AOFRW, and when we
are doding appendonly no, we will call stopAppendOnly to stop it.
In stopAppendOnly, the aof_fd is -1 since the aof is not start yet
and the fsync and close will take the -1 and call it, so they will
all fail with EBADF. And stopAppendOnly will emit a server log, the
close(-1) should be no problem but it is still an undefined behavior.

This PR also adds a log `Background append only file rewriting
scheduled.` to bgrewriteaofCommand when it was scheduled.
And adds a log in stopAppendOnly when a scheduled AOF is canceled,
it will print  `AOF was disabled but there is a scheduled AOF background, cancel it.`

Signed-off-by: Binbin <[email protected]>
Co-authored-by: Viktor Söderqvist <[email protected]>
Signed-off-by: mwish <[email protected]>
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