# Conflicts:
#	storage/innobase/btr/btr0pcur.cc
#	storage/innobase/log/log0log.cc

Fixed a condition where designated group commit lead was woken in release,
but returned early without trying to take over the lock.

So, the group commit locks would be unowned, and the waiters could
be stalled, until another thread comes that would on whatever reasons
flush the redo log.

Also, use better criteria for choosing potential next group commit lead.

To close a non-instrumented file, os_file_close_func() should be used
instead of os_file_close().

The performance_schema counter wait/io/file/innodb/innodb_log_file
is always reported as 0.

The way how redo log writes are being waited for was refactored in
commit 30ea63b7 by the introduction
of flush_lock and write_lock. Even before that change, all the
wait/io/file/innodb/ counters were always 0 in my tests.

Moreover, if the PMEM interface that was introduced in
commit 3daef523
is being used, writes to the InnoDB log file will completely avoid
any system calls and performance_schema instrumentation.
In commit 685d958e also the reads
of the redo log (during recovery) would bypass any system calls.

MDEV-20605 Awaken transaction can miss inserted by other transaction records due to wrong persistent cursor restoration

Post-push fix: remove unstable test.

The test was developed to find the reason of duplicated rows caused by
MDEV-20605 fix. The test is not necessary as the reason was found and
the bug was fixed.

log_t::rename_resized(): Replaces create_log_file_rename()

delete_log_files(): Moved to a separate function. Also invoked
on a normal startup when the log is not being resized, to
remove any garbage log files.

create_log_file(): Remove the std::string& parameter.

os_file_delete_if_exists_func() [_WIN32]: Do not retry DeleteFile()
on ERROR_ACCESS_DENIED.

The write_lock is released after the first time already.

This leaves the hole in the log_write_and_flush logic, some
flush_lock/write_lock waiters could be hanging, until the
background redo log flush comes.

The possibility of that is relatively tiny though.

MDEV-20605 Awaken transaction can miss inserted by other transaction records due to wrong persistent cursor restoration

sel_restore_position_for_mysql() moves forward persistent cursor
position after btr_pcur_restore_position() call if cursor relative position
is BTR_PCUR_ON and the cursor points to the record with NOT the same field
values as in a stored record(and some other not important for this case
conditions).

It was done because btr_pcur_restore_position() sets
page_cur_mode_t mode  to PAGE_CUR_LE for cursor->rel_pos ==  BTR_PCUR_ON
before opening cursor. So we are searching for the record less or equal
to stored one. And if the found record is not equal to stored one, then
it is less and we need to move cursor forward.

But there can be a situation when the stored record was purged, but the
new one with the same key but different value was inserted while
row_search_mvcc() was suspended. In this case, when the thread is
awaken, it will invoke sel_restore_position_for_mysql(), which, in turns,
invoke btr_pcur_restore_position(), which will return false because found
record don't match stored record, and
sel_restore_position_for_mysql() will move forward cursor position.

The above can lead to the case when awaken row_search_mvcc() do not see
records inserted by other transactions while it slept. The mtr test case
shows the example how it can be.

The fix is to return special value from persistent cursor restoring
function which would notify its caller that uniq fields of restored
record and stored record are the same, and in this case
sel_restore_position_for_mysql() don't move cursor forward.

Delete-marked records are correctly processed in row_search_mvcc().
Non-unique secondary indexes are "uniquified" by adding the PK, the
index->n_uniq should then be index->n_fields. So there is no need in
additional checks in the fix.

If transaction's readview can't see the changes made in secondary index
record, it requests clustered index record in row_search_mvcc() to check
its transaction id and get the correspondent record version. After this
row_search_mvcc() commits mtr to preserve clustered index latching
order, and starts mtr. Between those mtr commit and start secondary
index pages are unlatched, and purge has the ability to remove stored in
the cursor record, what causes rows duplication in result set for
non-locking reads, as cursor position is restored to the previously
visited record.

To solve this the changes are just switched off for non-locking reads,
it's quite simple solution, besides the changes don't make sense for
non-locking reads.

The more complex and effective from performance perspective solution is
to create mtr savepoint before clustered record requesting and rolling
back to that savepoint after that. See MDEV-27557.

One more solution is to have per-record transaction id for secondary
indexes. See MDEV-17598.

If any of those is implemented, just remove select_lock_type argument in
sel_restore_position_for_mysql().

Before commit 86dc7b4d (MDEV-24626)
all tablespace ID that needed recovery were known already in
recv_init_crash_recovery_spaces().

recv_sys_t::recover_deferred(): Invoke fil_names_dirty(space) on
the newly initialized tablespace. In this way, if the next log
checkpoint occurs at some LSN that is after the initialization of
the tablespace and before the last recovered LSN, a FILE_MODIFY
record will be written, so that a subsequent recovery will succeed.

The recovery was broken when
commit 0261eac5 merged the 10.5
commit f443cd11 (MDEV-27022).

Fixed inlining flags. Remove /Ob1 added by CMake for RelWithDebInfo.
(the actual compiler default is /Ob2 if optimizations are enabled)

Allow to define custom /Ob flag with new variable MSVC_INLINE, if desired

- regression got revealed while running tpcc workload.

- as part of MDEV-25919 changes logic for statistics computation was revamped.

- if the table has changed to certain threshold then table is added to
  statistics recomputation queue (dict_stats_recalc_pool_add)

- after the table is added to queue the background statistics thread is
  notified

- during revamp the condition to notify background statistics threads was
  wrongly updated to check if the queue/vector is empty when it should
  check if there is queue/vector has entries to process.

- vec.begin() == vec.end() : only when vector is empty

- also accessing these iterator outside the parallely changing vector is not
  safe

- fix now tend to notify background statistics thread if the logic adds
  an entry to the queue/vector.