maria-developers team mailing list archive

["Vladislav Vaintroub" <wlad@xxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Kristian Nielsen [mailto:knielsen@xxxxxxxxxxxxxxx]
> Sent: Freitag, 27. Januar 2012 11:53
> To: maria-developers@xxxxxxxxxxxxxxxxxxx
> Cc: Vladislav Vaintroub
> Subject: Re: [Commits] Rev 3241: Xtradb recently started to access thd
> members directly , e.g thd->stmt_da (ha_innodb.cc) in file:///H:/bzr/5.5/
> 
> Vladislav Vaintroub <wlad@xxxxxxxxxxxxxxxx> writes:
> 
> >   Xtradb  recently started to access thd members directly ,e.g
thd->stmt_da
> (ha_innodb.cc)
> >   It needs recompilation for embedded server, as layout of THD is
different in
> embedded.
> 
> Did you consider instead fixing XtraDB to not access thd members directly?
> Eg. using proper accessors, maybe adding new accessors if needed?
> Or is this not possible for some reason?

My first intention was to remove this line. I removed . I had not have any
assertions. Test (percona_fake_changes  iirc)  just did not pass.

The traditional way of fixing such things (for Innodb) is to extend server
API with yet another function, so that members of THD are not directly
accessed. Often new function appear inside #ifdef
INNODB_COMPATIBILITY_HOOKS.  In this case adding e.g
thd_clean_diagnostic_area(THD *) , would be what you mean by adding another
accessor.  It is not impossible, and should work. 

This can be solved either way, one is to fix Percona's code + to pollute
server API with questionable functionality, another one is
RECOMPILE_FOR_EMBEDDED. Neither is a nice one. I opted for recompile, since
this appeared more future proven to me - it is now prepared to handle all
future thd->foo references, who knows how many we'll see.

> It would be much preferable if XtraDB didn't mess with server internals
like
> this ...

Yes, I agree .


>  - Kristian.