Hi Sergei, On Tue, Apr 07, 2015 at 07:02:46PM +0200, Sergei Golubchik wrote: > Hi, Sergey! > > On Apr 07, Sergey Vojtovich wrote: > > On Tue, Apr 07, 2015 at 03:03:39PM +0200, Sergei Golubchik wrote: > > > On Apr 07, [email protected] wrote: > > > > > > > > MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed > > > > to discover table > > > > > > No, I don't like this solution. This is an issue in discovery, there is > > > nothing wrong with how P_S uses it. > > > > > > I'd rather fix it in TABLE_SHARE::init_from_sql_statement_string() > > > by temporarily setting THD::db to this->db (which is a db where the > > > table will be created). > > Well, I don't like it either. I also thought about temporary substition of > > THD::db. But it may be read by concurrent thread (at least SHOW PROCESSLIST > > does it) and be source for race conditions. Not sure how much these races > > are > > relevant though. > > Relevant. We've had these races with thd->query_string - and quite a few > of them. > > But I think they shouldn't be an issue in this case, because you won't > free either thd->db or TABLE_SHARE::db. That is, any concurrent SHOW > PROCESSLIST will see a valid string and will use it just fine. So I > don't think this will cause any issues. I won't free thd->db indeed. But I'm not that optimistic wrt TABLE_SHARE::db: e.g. tdc_acquire_share() will free table share on error. Anyway we can easily protect this by LOCK_thd_data.
What I'm mostly concerned about is that end user may see this temporary database substition. Do you think it is acceptable? Thanks, Sergey _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
