maria-developers team mailing list archive

[Sergey Petrunia <sergey@xxxxxxxxxxx>]

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