I also thought about removing it, but then decided to let the author to fix it, here is an urgent fix because as the previous bug showed, our client hit this problem. There is also "cuted_fields+= backup->cuted_fields;" which is very suspicious. On Fri, Jul 21, 2023 at 11:41 AM Sergei Golubchik wrote:

Hi, Oleksandr,

On Jul 21, Oleksandr Byelkin wrote:

...

revision-id: 64ac6ed3e35 (mariadb-10.4.30-31-g64ac6ed3e35) parent(s): 55a27bac80c author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2023-07-19 16:14:39 +0200 message:

MDEV-31742 incorrect examined rows in case of stored function usage

The counter is global so we do not need add backup to it if we do not zero it after taking the backup.

diff --git a/sql/sql_class.cc b/sql/sql_class.cc index c9e86b6142c..7911c78b6e0 100644 --- a/sql/sql_class.cc +++ b/sql/sql_class.cc @@ -5568,7 +5568,6 @@ void THD::restore_sub_statement_state(Sub_statement_state *backup) The following is added to the old values as we are interested in the total complexity of the query */ - inc_examined_row_count(backup->examined_row_count);

may be backup->examined_row_count should be simply removed? Sub_statement_state::examined_row_count, I mean. Not saved, not restored?

There's also

void THD::add_slow_query_state(Sub_statement_state *backup) { affected_rows+= backup->affected_rows; bytes_sent_old= backup->bytes_sent_old; m_examined_row_count+= backup->examined_row_count;

it's not even using inc_examined_row_count().

Also examined_row_count is mentioned in comments in sql_class.cc, if you'll be removing it from Sub_statement_state, don't forget to fix comments to match.

...

cuted_fields+= backup->cuted_fields; DBUG_VOID_RETURN; }

Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org