maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Arjen" == Arjen Lentz <arjen@xxxxxxxxxxxxx> writes:

<cut>

>> Filtering on current database (or on whatever for row-based) might  
>> be more
>> feasible, though there would still be the additional overhead of  
>> decoding each
>> event before sending to each slave.

Arjen> Kristian, your comment, while sounding entirely sensible, is beyond  
Arjen> hilariously funny.

Arjen> Because currently, the db filtering works on the default db.
Arjen> So if you say ignore-db bar, and your default db is foo, and then you  
Arjen> do INSERT INTO bar.t1. it'll happily insert.

That was something that was done by design and consensus, after
talking with developers and user of MySQL.

This solved tricky issues when you had statements with more than one
database involved.  The solution has it's pitfalls, as you showed, but
it was then to be best solution we could come up with.

But enough about history...

Arjen> There's also an intrinsic potential race condition with either method,  
Arjen> when dealing with multi-table update and delete:
Arjen> what do you do if one db is allowed and the other is not?

And INSERT .... SELECT ...

>> But it is good to keep in mind that the general problem has wider  
>> scope,
>> thanks for your comment!

Arjen> Ye spending time on the existing stuff just seems like a waste to me.
Arjen> I'd rather see something more sensible, even if it's still on basis of  
Arjen> current db. That'd already be more valuable.

We have to work with the existing stuff, as the intention is to be a
drop-in replacement of MySQL.

There are a lot of users that are depending on the current model and
we can't just 'fix' things without thinking through things...

So the right way to go forward is with small steps and add do it with
new options that doesn't break old behavior.

Regards,
Monty