maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

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, svoj@xxxxxxxxxxx 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