Hi, Sergei! On Nov 07, Sergei Petrunia wrote:
revision-id: 1a4031d9c8f314896daf8f7c19d6172b9bba313b (mariadb-10.3.10-49-g1a4031d9c8f) parent(s): e058a251c10350f3727ca1df022dc5786933535b author: Sergei Petrunia committer: Sergei Petrunia timestamp: 2018-11-07 11:58:30 +0300 message:
MDEV-17297: stats.records=0 for a table of Archive engine when it has rows, when we run ANALYZE command ... diff --git a/storage/archive/ha_archive.cc b/storage/archive/ha_archive.cc index 487c0038239..9d7f7e66b28 100644 --- a/storage/archive/ha_archive.cc +++ b/storage/archive/ha_archive.cc @@ -1737,6 +1721,38 @@ int ha_archive::info(uint flag) }
+int ha_archive::external_lock(THD *thd, int lock_type) +{ + if (lock_type == F_RDLCK) + { + // We are going to read from the table. Flush any pending writes that we + // may have + flush_and_clear_pending_writes(); + } + return 0; +}
This is somewhat unexpected. Normally buffers are flushed at the end of a statement, on F_UNLCK. For example, you'll have a better chance of surviving a crash (or kill -9). Otherwise I don't see much of a difference, so do it as you like. Shouldn't it go into 5.5, as the earliest affected version?
+void ha_archive::flush_and_clear_pending_writes() +{ + mysql_mutex_lock(&share->mutex); + if (share->dirty) + { + DBUG_PRINT("ha_archive", ("archive flushing out rows for scan")); + DBUG_ASSERT(share->archive_write_open); + azflush(&(share->archive_write), Z_SYNC_FLUSH); + share->dirty= FALSE; + } + + /* + This should be an accurate number now, though bulk and delayed inserts can + cause the number to be inaccurate. + */ + stats.records= share->rows_recorded; + mysql_mutex_unlock(&share->mutex); +}
Regards, Sergei Chief Architect MariaDB and security@mariadb.org