On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert(a)hendrickx.be wrote:
On Mon, Sep 21, 2015 at 12:28:35 -0700, Quanah Gibson-Mount wrote:
> The rationale was that manageDSAit means let me operate on the raw data and
> disable all side-effects. This is still correct and should remain.
For clarity I do agree that a control should exist to bypass uniqueness
(and other) constraints. However I think manageDSAit is not the
appropriate control by its definition, and also in practice given the
fact it's set per default by popular client libs.
Relax Rules seems much more appropriate for this use case, as it's intended
to temporarily relax database constraints, for administrative use only.
Yes, Relax control is better for manual bypass. We just need to make
sure the original issue that this code was created to address is not
reintroduced. ITS#6641 was put up to allow replication to bypass this
overlay and anything that was already loaded to one master should
happily replicate everywhere else. At that point, manageDSAit was the
only way I could find to distinguish an operation coming from syncrepl,
it seems that the constraint overlay has a more reliable check so that
might be a better idea.
Patch to that effect is here: