- developers - lists.mariadb.org

Re: [Maria-developers] Please review MDEV-12199 Split Item_func_{abs|neg|int_val}::fix_length_and_dec() into methods in Type_handler
by Alexander Barkov 10 Mar '17

10 Mar '17

Hello Alexey, On 03/10/2017 10:56 AM, Alexey Botchkov wrote: > Ok, i see. > > Last question then. > - item->cast_to_int_type() == cast_to_int_type() && > + item->cast_to_int_type_handler() == > cast_to_int_type_handler() && > Are you sure we should compare typehandlers here, not their ->cmp_type()? Item_hex_constant can be: 1. Either Item_hex_hybrid, which can act as a string or as a number, depending on context: SELECT 0x30, 0x30+1; +------+--------+ | 0x30 | 0x30+1 | +------+--------+ | 0 | 49 | +------+--------+ (the first 0x30 is a string '0', the second 0x30 is an integer 0x30, which is decimal 48) 2. Or Item_hex_string, which is always a string: SELECT X'30', X'30'+1; +-------+---------+ | X'30' | X'30'+1 | +-------+---------+ | 0 | 1 | +-------+---------+ (both X'30's are strings '0') The method Item_hex_constant::eq() needs to make sure that X'30' and 0x30 are considered as different items, and thus don't replace each other, e.g. in equal field propagation. Item_hex_hybrid::cast_to_int_type_handler() returns &type_handler_longlong. Item_hex_string::cast_to_int_type_handler() returns &type_handler_varchar. Comparing type handlers should be enough here. Comparing cmp_type() would be also correct, but would involve one extra virtual call, which is nice to avoid. > > Also i don't like that we have the 'val_int_signed_typecast' as a > virtual functions. Code would > be much nicer without that and all it was done just for Item_dyncol_get. > Not that simple to fix it though and I agree that it shouldn't be > touched as a part of this patch. > Probably sometime later... Maybe. Perhaps some related code will also migrate to Type_handler. Probably this would do: virtual longlong Type_handler::val_int_signed_typecast(Item *item); But I'm not 100% sure. Let's return to this later. Thanks! > > Best regards. > HF > > > > On Fri, Mar 10, 2017 at 1:10 AM, Alexander Barkov <bar(a)mariadb.org > <mailto:bar@mariadb.org>> wrote: > > Hello Alexey, > > > On 03/09/2017 11:38 PM, Alexey Botchkov wrote: > > Hi, Alexander. > > > > Some questions about the patch. > > > > I don't get why we have two sets of functions > > Type_handler_**::+bool > > Type_handler_int_result::Item_func_abs_fix_length_and_dec > > and > > Type_handler_**::+bool > > Type_handler_int_result::Item_func_neg_fix_length_and_dec > > > > As far as i can see these are equal and we just can have one > > Type_handler_**::+bool > > Type_handler_int_result::Item_func_abs_neg_fix_length_and_dec > > Did I miss something? > > > They might look similar: > > > bool Type_handler_int_result:: > Item_func_abs_fix_length_and_dec(Item_func_abs *item) const > { > item->fix_length_and_dec_int(); > return false; > } > > bool Type_handler_int_result:: > Item_func_neg_fix_length_and_dec(Item_func_neg *item) const > { > item->fix_length_and_dec_int(); > return false; > } > > > But they have arguments of different pointer types! > > > The former calls Item_func_abs::fix_length_and_dec_int(), and > the latter calls Item_func_neg::fix_length_and_dec_int(), > > and those are different. > > > > > Secondly, since Item_func::fix_length_and_dec() was historically 'void' > > and i don't see you're > > changing it, why do all these typehandler's 'xxx_fix_length_and_dec' > > return something? > > Nobody checks their return anyway. > > > Currently fix_fields() does this: > > fix_length_and_dec(); > if (thd->is_error()) // An error inside fix_length_and_dec occurred > return TRUE; > > I'm thinking of eventually changing this to: > > if (fix_length_and_dec()) > return true; > > > So I decided to make all Type_handler::xxxx_fix_length_and_dec() > return bool right now, so we have to do less changes in the future. > > > Thanks! > > > > > Best regards. > > HF > > > > > > On Tue, Mar 7, 2017 at 6:15 PM, Alexander Barkov <bar(a)mariadb.org <mailto:bar@mariadb.org> > > <mailto:bar@mariadb.org <mailto:bar@mariadb.org>>> wrote: > > > > Hello Alexey, > > > > Please review a patch for MDEV-12199. > > > > Thanks! > > > > > >

1 0

[Maria-developers] GTID and Optimize, Analyze etc
by Peter Mclarty 10 Mar '17

10 Mar '17

Hi I have some very large tables and I would like to give them a cleanup. If I run OPTIMIZE and ANALYZE on a slave does that affect the GTID of that slave and cause me to eventually get the dreaded Slave has diverged too far from the master type error Can I set a session variable to block any change Cheers -- *Cheers* *Peter McLarty* -- Compare The Market is a brand and trading name of Compare The Market (Pty) Ltd (CTM). This email is for the intended addressee and is confidential and subject to copyright. If you are not the intended addressee, confidentiality has not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify CTM and then delete the email. CTM does not warrant that this email is error or virus free.

2 1

Re: [Maria-developers] Please review MDEV-12199 Split Item_func_{abs|neg|int_val}::fix_length_and_dec() into methods in Type_handler
by Alexander Barkov 09 Mar '17

09 Mar '17

Hello Alexey, On 03/09/2017 11:38 PM, Alexey Botchkov wrote: > Hi, Alexander. > > Some questions about the patch. > > I don't get why we have two sets of functions > Type_handler_**::+bool > Type_handler_int_result::Item_func_abs_fix_length_and_dec > and > Type_handler_**::+bool > Type_handler_int_result::Item_func_neg_fix_length_and_dec > > As far as i can see these are equal and we just can have one > Type_handler_**::+bool > Type_handler_int_result::Item_func_abs_neg_fix_length_and_dec > Did I miss something? They might look similar: bool Type_handler_int_result:: Item_func_abs_fix_length_and_dec(Item_func_abs *item) const { item->fix_length_and_dec_int(); return false; } bool Type_handler_int_result:: Item_func_neg_fix_length_and_dec(Item_func_neg *item) const { item->fix_length_and_dec_int(); return false; } But they have arguments of different pointer types! The former calls Item_func_abs::fix_length_and_dec_int(), and the latter calls Item_func_neg::fix_length_and_dec_int(), and those are different. > > Secondly, since Item_func::fix_length_and_dec() was historically 'void' > and i don't see you're > changing it, why do all these typehandler's 'xxx_fix_length_and_dec' > return something? > Nobody checks their return anyway. Currently fix_fields() does this: fix_length_and_dec(); if (thd->is_error()) // An error inside fix_length_and_dec occurred return TRUE; I'm thinking of eventually changing this to: if (fix_length_and_dec()) return true; So I decided to make all Type_handler::xxxx_fix_length_and_dec() return bool right now, so we have to do less changes in the future. Thanks! > > Best regards. > HF > > > On Tue, Mar 7, 2017 at 6:15 PM, Alexander Barkov <bar(a)mariadb.org > <mailto:bar@mariadb.org>> wrote: > > Hello Alexey, > > Please review a patch for MDEV-12199. > > Thanks! > >

1 0

[Maria-developers] INFORMATION_SCHEMA.SCHEMATA and INFORMATION_SCHEMA.SCHEMA_PRIVILEGES
by Witold Filipczyk 09 Mar '17

09 Mar '17

Hi, I'm newbie, I have problem with INFORMATION_SCHEMA. There is mariadb-10.0 with around 100000 databases. Disks are slow, but most users have one database, a few have more than one, but it is not a big number. Queries like SHOW DATABASES or SELECT * FROM INFORMATION_SCHEMA.SCHEMATA bring to knees whole server. The idea to resolve it is: in find_files(...) instead of the for loop execute query: SELECT REPLACE(TABLE_SCHEMA, '\\', '') FROM INFORMATION_SCHEMA.SCHEMA_PRIVILEGES WHERE PRIVILEGE_TYPE = 'SELECT'; There are databases with names with _ in them and \_ in GRANTS. This is theory, but I don't know how to do it. That's mean how to freeze the current query, how to run new query, read results, and fill files in the find_files function and resume the current query. Could you help? Or do you have ideas how to solve it? -- Witold Filipczyk

2 3

[Maria-developers] Maria db read/write configuration issues
by Chaitanya Cheekate 09 Mar '17

09 Mar '17

Hi We have configured maxscale in our environment using the links http://karlssonondatabases.blogspot.in/2014/02/maxscale-for-rest-of-us-part…, 2, 3 . We have two slaves and one master and the replication between them is working well. But after configuring read/write split the select queries are being executed in master itself, not routing to the slaves. Please find the attached documents of maxscale configuration, maxscale commands maxscale log and. Please help with maxscale read/write split. Attached documentsdetails 1. maxsconf.txt from the location /etc/maxscale.cnf 2. maxscale-commands.txt, coomands like maxadmin -pmariadb list servers, maxadmin -pmariadb list services, maxadmin -pmariadb show service "Splitter Service", 3. maxscale-log.txt from /var/log/maxscale Thanks Chaitu -- Thanks.

3 3

Re: [Maria-developers] 440e040: MDEV-11941 - Lintian complains about executable bits
by Sergei Golubchik 07 Mar '17

07 Mar '17

Hi, Sergey! Ok to push, of course. On Mar 03, Sergey Vojtovich wrote: > revision-id: 440e040a2421ad0d3ad3a059f1c4d5ffbf94a271 (mariadb-10.1.21-44-g440e040) > parent(s): 88b5eedef2b1f235346adf9aeca05c4ebab9921c > committer: Sergey Vojtovich > timestamp: 2017-03-03 12:33:24 +0400 > message: > > MDEV-11941 - Lintian complains about executable bits Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] c6a38fd: MDEV-10646 - System Unit File After network-online
by Sergei Golubchik 07 Mar '17

07 Mar '17

Hi, Sergey! On Mar 07, Sergey Vojtovich wrote: > revision-id: c6a38fd974d43aa9094e215969fa3598c595f7b0 (mariadb-10.1.21-50-gc6a38fd) > parent(s): e6aa08ced29d4dab120ae2dc8c08f6b3b81e0c93 > committer: Sergey Vojtovich > timestamp: 2017-03-07 15:06:01 +0400 > message: > > MDEV-10646 - System Unit File After network-online > > Bind to an address even if it is not yet configured. Looks ok to me Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] Adding information de Information_schema.processlist
by jerome brauge 07 Mar '17

07 Mar '17

Hello, Connector/J support the method setClientInfo and standard information : ApplicationName, ClientUser and ClientHostname. (https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setClien… It's seem that there is no way to see these information by a select because session variables are used to store these values. Can we add these information as columns in Information_schema.processlist ? Regards, Jérôme.

1 0

[Maria-developers] Please review MDEV-12199 Split Item_func_{abs|neg|int_val}::fix_length_and_dec() into methods in Type_handler
by Alexander Barkov 07 Mar '17

07 Mar '17

Hello Alexey, Please review a patch for MDEV-12199. Thanks!

1 0

[Maria-developers] MDEV-11829 RFC3339 Support
by Seth Shelnutt 05 Mar '17

05 Mar '17

Hello, This is in response to the comments on the initial pull request I made for adding RFC3339 support [1]. The proposal is to add support for parsing RFC3339 and then use the given timezone offset to shift the datetime. I think most users would expect the behavior to be converted to the timezone of the mariadb server / session as defined in THD. Most timezone operations are depended on the session specified timezone, whether that is set or inherited from global timezone, or system timezone. In order to convert from RFC3339 timezone to session timezone, we will need to return the timezone from the str_to_datetime function. As mentioned there is no timezone member of the MY_TIME struct. I believe a change to the MY_TIME struct would be the most beneficial and cleanest approach. This would allow for handling RFC3339 and future additions, such as a datetime with time zone field, similar to the ansi timestamp with time zone. The struct is used in a several ways, including packing into longlong, all of those cases would need to be handled. This would be a much larger and more involved patchset. An alternative approach, that is less involved, would be use the MYSQL_TIME_STATUS struct to indicate that a timezone offset exists. An offset field and indicator could be added right to the status struct, or a new warning can be used to indicate it exists in the raw string. Then the caller of str_to_datetime can handle the timezone conversion. A third approach, would be to change the function signature of str_to_datetime and provide a variable to store the offset in, if exists. I'm sure what the general stance is on altering entire function calls, especially one that is older and quite important. With any approach, the timezone could then be handled outside of my_time.c, where we have THD and the timezone class, which can easily handle the conversion. I will start working on this once I receive some feedback on the general direction that would result in an acceptable patchset. [1] https://github.com/MariaDB/server/pull/290 Thank you, Seth Shelnutt

3 4