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

MDEV-35694: Mysqlbinlog --stop-position should warn if EOF not reached with --read-from-remote-server #3757

Open
wants to merge 2 commits into
base: 10.5
Choose a base branch
from

Conversation

bnestere
Copy link
Contributor

MDEV-27037 added functionality to warn users that a specified
stop-position or stop-datetime was never reached. It only worked for
local files though. The patch in MDEV-35528 changed the
implementation for stop-datetime to work to provide the warning also
when using --read-from-remote-server. The PR for that MDEV (#3670)
was limited to only the stop-datetime field.

This patch updates the --stop-position warning to also work with
--read-from-remote-server.

This PR is organized as follows:

  1. The first commit shows the regression (as a missing warning in the
    result when running binlog.binlog_mysqlbinlog_warn_stop_position
  2. The second commit is the fix.

MDEV-35694: Mysqlbinlog --stop-position should warn if EOF not reached with --read-from-remote-server

MDEV-27037 added functionality to warn users that a specified
stop-position or stop-datetime was never reached. It only worked for
local files though. The patch in MDEV-35528 changed the
implementation for stop-datetime to work to provide the warning also
when using --read-from-remote-server. The PR for that MDEV (#3670)
was limited to only the stop-datetime field.

The regression shows as a lack of an error message when running
binlog.binlog_mysqlbinlog_warn_stop_position
…d with --read-from-remote-server

MDEV-27037 added functionality to warn users that a specified
stop-position or stop-datetime was never reached. It only worked for
local files though. The patch in MDEV-35528 changed the
implementation for stop-datetime to work to provide the warning also
when using --read-from-remote-server. The PR for that MDEV (#3670)
was limited to only the stop-datetime field.

This patch updates the --stop-position warning to also work with
--read-from-remote-server.

Reviewed By:
============
<TODO>
Comment on lines 144 to +146
static ulonglong start_position, stop_position;
static const longlong stop_position_default= (longlong)(~(my_off_t)0);
static ulonglong last_processed_position= 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

The comparison down there looks so wrong having to cast (C-style or static_const).
Will an unsigned do? Or even a this-file-only macro-constant?

Suggested change
static ulonglong start_position, stop_position;
static const longlong stop_position_default= (longlong)(~(my_off_t)0);
static ulonglong last_processed_position= 0;
static ulonglong start_position, stop_position;
#define stop_position_default ~0ULL
static ulonglong last_processed_position= 0;

or ULLONG_MAX or std::numeric_limits<unsigned long long>::max()


Rather, specializing this value would put ~0 as an input out of support, though I don’t think it has a practical difference from “your file is bigger than the legal limit”.

Comment on lines 3133 to +3143
warning("Did not reach stop datetime '%s' before end of input",
stop_datetime_str);

/*
Emit a warning in the event that we finished processing input
before reaching the boundary indicated by --stop-position.
*/
if ((static_cast<longlong>(stop_position) != stop_position_default) &&
stop_position > last_processed_position)
warning("Did not reach stop position %llu before end of input",
stop_position);
Copy link
Contributor

@ParadoxV5 ParadoxV5 Jan 14, 2025

Choose a reason for hiding this comment

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

☑️ Things are consistent with --stop-datetime (MDEV-35528).

Funny. The code used to check/warn datetime after position, but now it’s before. 😀
No need to swap back though. Positions are “absolute” while datetime (which can go out-of-order) are “relative”, so it feels intuitive to have that last.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants