On Mon, 15 Mar 2010 12:29:14 +0100, Kristian Nielsen
wrote:
>> 2) It correctly identifies that (the part of) ID should be a monotonic
>> ordinal number.
>
> Ok. But should it increase in order of transaction start? Or in order of
> transaction commit?
I think this is easy: until transaction is
At file:///home/tsk/mprog/src/5.3-subqueries/
revno: 2780
revision-id: tim...@askmonty.org-20100315224130-321rym1lsuwz2j5z
parent: tim...@askmonty.org-20100315195258-nhomb3anbb1tv3mi
committer: tim...@askmonty.org
branch nick: 5.3-subque
#At file:///home/tsk/mprog/src/5.3-subqueries/ based on
revid:tim...@askmonty.org-20100315195258-nhomb3anbb1tv3mi
2780 tim...@askmonty.org 2010-03-16
MWL#68: Subquery optimization: Efficient NOT IN execution with NULLs
Fix for the PBXT copy of subselect.test.
modifi
Hi Kristian,
I agree with Alex's response, and I'll pick the hopefully all the
remaining questions to answer here.
Quoting Kristian Nielsen :
So the basic for such an interface would be the ability to install
hooks to be
called with row data for every handler::write_row(), handler::update_
On Mon, 15 Mar 2010 10:57:41 +0100, Kristian Nielsen
wrote:
>
> Right.
>
> So if I understand you correctly, with "internal implementation details"
> we do
> not mean just that the APIs expose internals of the SQL server which we
> want
> to shield plugins from. Rather, the way the interface is
Daniel Bartholomew wrote:
> On Sat, 13 Mar 2010 09:34:22 +0100
> Kristian Nielsen wrote:
>
> Kristian> One thing we could do is disable the worklog...@askmonty.org
> Kristian> alias (eg. send it to /dev/null). This should disable sending
> Kristian> the mails to the mailing list at least.
>
> I
On Sat, 13 Mar 2010 09:34:22 +0100
Kristian Nielsen wrote:
Kristian> One thing we could do is disable the worklog...@askmonty.org
Kristian> alias (eg. send it to /dev/null). This should disable sending
Kristian> the mails to the mailing list at least.
I am in favor of doing this to improve the s
Hi!
> "Sergei" == Sergei Golubchik writes:
>>> 2. Unknown option should be an error by default.
>>
>> OK. The only problem is that it is contradict to Monty requirements.
>> Our initial decision was issue error if option was added explicitly.
>> The only problem is that it is very diffic
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
---
WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...: New replication APIs
CREATION DATE..: Mon, 15 Mar 2010, 13:55
SUPERVISOR.: Knielsen
IMPLEME
And the data is the important part... I think it's a good idea, but I am
just trying to bring up a counterpoint that might not have been discussed.
On Mar 15, 2010 9:08 AM, "Timour Katchaounov" wrote:
Adam,
> I might also add...
>
> *What happens when/if Canonical/Ubuntu goes bunk?
>
> Using
Adam,
I might also add...
*What happens when/if Canonical/Ubuntu goes bunk?
Using all of the tools provided by one vendor can be a great thing but not
if the vendor's existence is "tenuous." If that happens, how easy would it
be to migrate data away from the vendor and would we even have that
I might also add...
*What happens when/if Canonical/Ubuntu goes bunk?
Using all of the tools provided by one vendor can be a great thing but not
if the vendor's existence is "tenuous." If that happens, how easy would it
be to migrate data away from the vendor and would we even have that option?
Robert Hodges writes:
> First of all, we Continuent Tungsten folk have a certain set of problems we
> solve with replication. Here are the key use cases:
> 3. Replicating heterogeneously between MySQL and other database like Oracle.
> This requires the ability to filter and transform data easil
Alex Yurchenko writes:
> The global transaction ID is a cornerstone concept of a any replication
> system which aspires to be pluggable, extensible and go beyond basic
> master-slave. It is hardly possible to even start designing the rest of the
> API without first setting on global transaction I
On Wed, Mar 3, 2010 at 6:07 PM, Sergei Golubchik wrote:
> ability to remove hours
> Somebody mentioned that a number of hours could be
> increased by mistake, and there should be a way to decrease
> is back. I'm not convinced it's a good idea, though.
Then again, it should also not be e
On Wed, Mar 3, 2010 at 6:07 PM, Sergei Golubchik wrote:
> Feel free to suggest more or "get rid of WL, use X instead",
Just to update you on discussion we've had last August (I think).
Our, or at least my, current thinking is that worklog is currently
used as a "default" option since it is the t
Alex Yurchenko writes:
> On Mon, 25 Jan 2010 13:55:44 +0100, Kristian Nielsen
> wrote:
>>
>> I think it would be useful if you explained what the problems are with
> that
>> interface, in your opinion.
> This interface does not seem to improve anything about how redundancy is
> achieved in MyS
23 matches
Mail list logo
