Re: [Maria-developers] 1a4031d9c8f: MDEV-17297: stats.records=0 for a table of Archive engine when it has rows, when we run ANALYZE command
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
On Wed, Jan 23, 2019 at 04:11:58PM +0100, Sergei Golubchik wrote:
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.
There is a difference. Consider a bulk load: INSERT INTO archive_table ...; INSERT INTO archive_table ...; ... If we flush at statement end, the above fill do a flush after each statement. If we flush in external_lock(F_RDLCK), the above will not flush, and potentially execute faster.
Shouldn't it go into 5.5, as the earliest affected version?
I assumed only security fixes should go into 5.5. If this fix is appropriate for 5.5, I'm fine with pushing it there.
+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); +}
BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog
participants (2)
-
Sergei Golubchik -
Sergey Petrunia