Andrei via developers <developers@lists.mariadb.org> writes: > So you're in this context > > 1 innobase_commit_by_xid(
> 18 thd_binlog_pos(thd, &trx->mysql_log_file_name, > 19 &trx->mysql_log_offset); > 20 if (trx->mysql_log_offset > 0) > 21 trx->flush_log_later = true; > > and actually considering `trx->mysql_log_offset` as the return value? > ... I could not grasp your way of thinking in this place. > Could you please expand on? My point was just, that what we want to do here is for the (internal) transaction coordinator to tell the storage engine that the engine does not need to fsync() for the commit to be durable, another fsync was already done to ensure this. This is what we in the normal commit path do by calling commit_ordered(), as documented sql/handler.h. The thd_binlog_pos() is completely unrelated, it's a way for the storage engine to get the binlog position corresponding to the commit, so that it can be stored transactionally inside the engine and used in a backup to provision a new slave. But now suddenly the durability of the commit_by_xid is determined by whether the thd_binlog_pos() sets the output parameter trx-->mysql_log_offset to non-zero. That's fragile from a maintenance point of view. > Xlle can't be generally avoided so we have to take conservatively first. Why it cannot be avoided? What is it needed for? - Kristian. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
