Hi, Alexander!
On May 04, Alexander Barkov wrote:
>
> If I run this query:
>
> SELECT 1 UNION SELECT 2 INTO OUTFILE 'test.txt';
>
> It creates a file 'test.txt' with this content:
>
> 1
> 2
>
> Looks fine so far.
>
> Now if I do "rm test.txt" and execute another query (with parentheses):
>
Hi, Vicențiu!
On 04.05.2016 18:50, Vicențiu Ciorbaru wrote:
Hi Sanja, Sergey,
I think Sergey might have mean the same thing but it is not clear to
me. in_optimize never gets set to true. By mentioning that it is
redundant that means that it can be removed from the current code right?
It was u
Hi Sanja, Sergey,
I think Sergey might have mean the same thing but it is not clear to me.
in_optimize never gets set to true. By mentioning that it is redundant that
means that it can be removed from the current code right?
Also, I would put the "return true" conditions after the "return false"
Hi Sanja,
I have one comment: the patch introduces JOIN::in_optimize which can have
values of 1) not initialized and 2) false. This is clearly redundant.
Ok to push after the above is addressed.
On Sun, Feb 21, 2016 at 10:12:25PM +0100, OleksandrByelkin wrote:
> revision-id: b1ddc7d546e6b147838a
Hi Sergei,
Thanks for the review!
On 04/27/2016 06:24 PM, Sergei Golubchik wrote:
Hi, Alexander!
The approach is fine. Two comments below:
The remaining heavy piece of the code is:
Item* propagate_equal_fields(THD *thd, const Context &ctx, COND_EQUAL *cond)
{
Context cmpctx(ANY_S
Hi Monty,
I vaguely recall you told me once that you like detached threads more than
joinable, specifically for service threads. Could you remind me what were
the reasons behind it?
I need this to fix https://jira.mariadb.org/browse/MDEV-9994 properly.
Thanks,
Sergey
___
> Your test here expects "either ER_BAD_DB_ERROR or a success".
> I asked - does that mean that even with your debug_sync points the
result is still non-deterministic?
Ah, got it.
The test is deterministic, so we should only wait for the BAD_DB_ERROR.
Will remove the '0'.
Best regards.
HF.
__
Hi, Alexey!
On May 04, Alexey Botchkov wrote:
> > Hm... If the default connection signals "locked" before you start
> > waiting for it now - will your test still work?
>
> Well the DEBUG_SYNC manual seems to be explicit about it:
> " A signal remains in effect until it is overwritten. If conn1 s
Hm... If the default connection signals "locked" before you start
waiting for it now - will your test still work?
Well the DEBUG_SYNC manual seems to be explicit about it:
" A signal remains in effect until it is overwritten. If conn1 signals
'opened' before conn2 reaches 'now', conn2 will st
9 matches
Mail list logo
