maria-developers team mailing list archive
Mailing list archive
Re: Rev 3712: MDEV-4338 : Support atomic option on directFS/FusionIO
> -----Original Message-----
> From: Laurynas Biveinis [mailto:laurynas.biveinis@xxxxxxxxx]
> Sent: Donnerstag, 4. April 2013 21:59
> To: Vladislav Vaintroub
> Cc: Sergei Golubchik; maria-developers@xxxxxxxxxxxxxxxxxxx;
> Subject: Re: [Maria-developers] Rev 3712: MDEV-4338 : Support atomic
> option on directFS/FusionIO
> >> > + srv_use_atomic_writes = (ibool) innobase_use_atomic_writes;
> >> Is that the typical usage pattern in the innodb code?
> >> Because it looks a bit silly to me, why couldn't you create a sysvar
> >> directly on srv_use_atomic_writes, why an intermediate
> >> innobase_use_atomic_writes variable?
> > Yes, this is typical usage pattern in Innodb. Bit weird, I agree. Every
> > innobase_xxx variable has an srv_xxx counterpart. I have no clue why it is
> > so, but I did not want to disturb their existing conventions:)
> FWIW not necessarily. Look at innodb_io_capacity,
> innodb_purge_batch_size, innodb_rollback_segments,
> innodb_purge_threads just name the first few where a srv_* variable is
> specified in MYSQL_SYSVAR_* directly. Note that the srv_* = innobase_*
> assignments have typecasts on them, so I haven't checked, but it might
> be that using the srv_ in a MYSQL_SYSVAR_ directly would have resulted
> in compilation warnings otherwise.
Thanks, Laurinas, this is interesting.
I tested it , using srv_use_atomic_writes directly.
This gives me compiler error, not warning :)
6>..\..\..\storage\xtradb\handler\ha_innodb.cc(12654): error C2440: 'initializing' : cannot convert from 'ulint *' to 'char *'
6> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Indeed, boolean values are handled consequently as "char" in MySQL (i.e my_bool is char ), and as "ulint" in innodb (ibool is ulint)
> Just 2c,