Re: [Maria-developers] ae2cb44: MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover
Hi, Sergey! On Apr 07, svoj@mariadb.org wrote:
revision-id: ae2cb445ea2a51657f1d2581db77db2ecbf70bc1 parent(s): 7d9e94e2e6c32b906d1d8469e58bc04b8da1c121 committer: Sergey Vojtovich branch nick: mariadb timestamp: 2015-04-07 14:59:25 +0400 message:
MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover table
Performance schema discovery fails if connection has no active database set.
This happened due to restriction in SQL parser: table name with no database name is ambiguous in such case.
Now PFS discovery statements specify database name explicitely.
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). Regards, Sergei
Hi Sergei, On Tue, Apr 07, 2015 at 03:03:39PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
On Apr 07, svoj@mariadb.org wrote:
revision-id: ae2cb445ea2a51657f1d2581db77db2ecbf70bc1 parent(s): 7d9e94e2e6c32b906d1d8469e58bc04b8da1c121 committer: Sergey Vojtovich branch nick: mariadb timestamp: 2015-04-07 14:59:25 +0400 message:
MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover table
Performance schema discovery fails if connection has no active database set.
This happened due to restriction in SQL parser: table name with no database name is ambiguous in such case.
Now PFS discovery statements specify database name explicitely.
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.
Thanks, Sergey
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@mariadb.org 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. Regards, Sergei
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@mariadb.org 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
Hi Sergei, On Tue, Apr 07, 2015 at 07:02:46PM +0200, Sergei Golubchik wrote: 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
participants (2)
-
Sergei Golubchik -
Sergey Vojtovich