On Fri, Aug 25, 2023 at 11:25 AM Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Binlog encryption is not something that I find very useful or interesting. It's one of those features that hurt more than it helps.
Yes, we have some of those in InnoDB as well.
For the binlog, the stmt/trx caches are written directly to the binlog file under LOCK_log, from a single thread serving multiple pending transactions.
I think that most InnoDB redo log record writes will be non-durable ones, to the shared log_sys.buf, which could be memory mapped a PMEM device, but typically is the a RAM buffer that will be explicitly written the ib_logfile0. Those writes are protected by two special synchronization devices in log0log.cc that implement "everything up to this LSN" semantics: static group_commit_lock write_lock; static group_commit_lock flush_lock;
+/* Convenience macros since ulong is 32 or 64 bit depending on platform. */ +#if SIZEOF_LONG == 4 +#define my_atomic_storeul(P, D) my_atomic_store32((int32 volatile *)(P), (D))
In all currently supported MariaDB Server versions, C++11 is available. Is there a particular reason why you would not use std::atomic<size_t> here?
Yes. The binlog_checksum_options variable needs to be of ulong type to be usable with the MYSQL_SYSVAR_ENUM() macro to define the --binlog-checksum configuration option. As far as I could determine, std::atomic does not provide any non-atomic access to the underlying storage location to obtain the ulong * required.
Oh, sorry, I should have written std::atomic<long>. We have sizeof(size_t)>sizeof(long) on LLP64 platforms, such as Microsoft Windows. I am successfully using a dirty trick like this: static SHOW_VAR innodb_status_variables[]= { … {"ibuf_merges", &ibuf.n_merges, SHOW_SIZE_T}, … {NullS, NullS, SHOW_LONG} }; The underlying C-style cast simply assumes that the Atomic_counter<ulint> can be read as a normal ulint (which is an alias for size_t). Theoretically, it might not work on some exotic architecture where std::atomic could add some "bloat". I am not aware if any such architecture exists, and I wouldn't expect the my_atomic_ interface to work either in such a case.
(The ulong type and sys_var was always a source of grief, with ulong being different size on different platforms and so on).
Right. I think that using "long" is usually a mistake, given that both LP64 and LLP64 are in widespread use. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc