This setting produced a ton of output, always in my experience.
The output itself should end up in the error log, this is where stdout/stderr
of the server process are redirected.
I do not have any other ideas as for how to troubleshoot Kerberos, except the
mentioned KRB5_TRACE and perhaps also
Vladislav,
I enabled the TRACE log. But that doesn't produce any logs for this issue.
Any other ideas?
Sincerely,
Saqib
http://saqib.org
On Fri, Jul 21, 2017 at 4:17 PM, Vladislav Vaintroub
wrote:
> Those errors come from GSSAPI/Kerberos APIs, they are not originated
> directly by the server.
Jocelyn,
the bug described there seems similar to my problem and it works on MariaDB
10.0.23.
[]s.
On Mon, Jul 24, 2017 at 1:31 PM, jocelyn fournier <
jocelyn.fourn...@softizy.com> wrote:
> Hi Alessandro!
>
>
> 10.0.31 should be affected by https://jira.percona.com/browse/TDB-35 , do
> you t
Hi Alessandro!
10.0.31 should be affected by https://jira.percona.com/browse/TDB-35 ,
do you think it could be related to your issue?
HTH,
Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
https://www.softizy.com
Softizy - At your side to Optimize your PHP / MySQL applications
Le 24/07/2017 à
Even if a change the order by and the query to include all 3 fields on the
index, it still selects the PRIMARY key to query the table.
Do you think this is a bug?
Tks.
On Mon, Jul 24, 2017 at 11:34 AM, Alessandro Ren
wrote:
>
>Once cached, the query returns in 0s.
>
>The force
Once cached, the query returns in 0s.
The force index solved the problem:
MariaDB 10.0.31
Force index:13 rows in set (2.31 sec)
No force: 13 rows in set (12.97 sec)
MariDB 10.0.25:
Force index: 13 rows in set (1.46 sec)
No force: 13 rows in set (1.70 sec)
Expl
MariaDB 10.0.25 - 13 rows in set (1.67 sec)
MariaDB 10.0.31 - 13 rows in set (29.06 sec)
+--+-+--+---++-+-+--+--+--+
| id | select_type | table| type
This is repeatable and it's still the same once data is cached?
Which version is the explain from? I guess it's from 10.0.31. Can you include
the explain from the other version(s)?
The DATE_FORMAT function part of the query…
AND ( ( Date_format(entry_time, '%w') = 0
AND ((
Hi Alessandro,
Can you by any chance provide the query plan for the previous version of
MariaDB? That can potentially help in diagnosing the problem. I haven't yet
looked into the issue, but it's good if we can eliminate the query
optimiser in case it's providing a different query plan.
Vicențiu
Hello,
I've noticed a great performance hit after I upgraded my MariaDB install to
10.0.28, 10.0.29, 10.0.30 and 10.0.31.
I even tried upgrading to MariaDB 10.2.7 and had the same problem. Bellow
de details.
MariaDB 10.0.25 - 13 rows in set (1.67 sec)
MariaDB 10.0.31 - 13 rows in set (29.06 sec)
10 matches
Mail list logo
