Am 13.08.2018 um 14:33 schrieb Sergei Golubchik:
> On Aug 13, Reindl Harald wrote:
>>
>>
>> Am 13.08.2018 um 12:22 schrieb Ling, Andy:
"The advantage of FLUSH TABLES table_name FOR EXPORT is that the table
is read locked until UNLOCK TABLES is executed" is not really true
because
Hi, Reindl!
On Aug 13, Reindl Harald wrote:
>
>
> Am 13.08.2018 um 12:22 schrieb Ling, Andy:
> >> "The advantage of FLUSH TABLES table_name FOR EXPORT is that the table
> >> is read locked until UNLOCK TABLES is executed" is not really true
> >> because that's only valid for the running
> Am 13.08.2018 um 12:22 schrieb Ling, Andy:
> >> "The advantage of FLUSH TABLES table_name FOR EXPORT is that the
> table
> >> is read locked until UNLOCK TABLES is executed" is not really true
> >> because that's only valid for the running connection
> >
> > Surely not. If you've locked a table
> On Aug 13, Ling, Andy wrote:
> >
> > The code doing this stops everything talking to the database (Yes, I
> > know there could be someone fiddling remotely in a shell, but this is
> > very unlikely). Even tables which are never written to cause this
> > error
> >
> > So if I'm careful, is there
Am 13.08.2018 um 12:27 schrieb Sergei Golubchik:
> On Aug 13, Ling, Andy wrote:
>>
>> The code doing this stops everything talking to the database (Yes, I
>> know there could be someone fiddling remotely in a shell, but this is
>> very unlikely). Even tables which are never written to cause this
Am 13.08.2018 um 12:22 schrieb Ling, Andy:
>> "The advantage of FLUSH TABLES table_name FOR EXPORT is that the table
>> is read locked until UNLOCK TABLES is executed" is not really true
>> because that's only valid for the running connection
>
> Surely not. If you've locked a table for read
Hi, Andy!
On Aug 13, Ling, Andy wrote:
>
> The code doing this stops everything talking to the database (Yes, I
> know there could be someone fiddling remotely in a shell, but this is
> very unlikely). Even tables which are never written to cause this
> error
>
> So if I'm careful, is there a
> >>> I'm using MariaDB 10.2.13 on Windows 7. All tables are using the Aria
> >>> engine.
> >>>
> >>> I am trying to initialise a slave database by copying the files between
> >>> PCs, but when I try and use the copied files I get the error
> >>>
> >>> Table is from another system and must be
Am 13.08.2018 um 11:57 schrieb Ling, Andy:
>>> I'm using MariaDB 10.2.13 on Windows 7. All tables are using the Aria
>>> engine.
>>>
>>> I am trying to initialise a slave database by copying the files between
>>> PCs, but when I try and use the copied files I get the error
>>>
>>> Table is from
Hi, Michal!
On Aug 13, Michal Schorm wrote:
> >
> > What if we just make mtr to do `exit 2` if it exists because of
> > --max-test-fail ?
>
> I'm afraid that won't help me in any way.
> In such case, still, no matter how many tests fail (if >0), the
> testsuite will fail. With different exit
Am 13.08.2018 um 11:30 schrieb Ling, Andy:
> I’m using MariaDB 10.2.13 on Windows 7. All tables are using the Aria
> engine.
>
> I am trying to initialise a slave database by copying the files between
> PCs, but when I try and use the copied files I get the error
>
> Table is from another
I'm using MariaDB 10.2.13 on Windows 7. All tables are using the Aria engine.
I am trying to initialise a slave database by copying the files between PCs,
but when I try and use the copied files I get the error
Table is from another system and must be zerofilled or repaired to be usable on
>
> What if we just make mtr to do `exit 2` if it exists because of
> --max-test-fail ?
>
I'm afraid that won't help me in any way.
In such case, still, no matter how many tests fail (if >0), the testsuite
will fail. With different exit code maybe, but it will fail.
I'm looking for an option
13 matches
Mail list logo
