On 2008-03-07 Fri 13:25 +0200，Andrei Elkin wrote：
> Zhen Xing, hello.
>
> Thanks for spelling out those subtle issues to me on #rep.
>
> [12:03]<andrei> jasonh: i see one important point now. slave does not know
> whether `set insert_id N; query' pair is after a stored
> procedure or not.
>
> However, my offering to be content with only having a doc lines
>
> [12:06]<andrei> jasonh: that means the warning about the buggy master does not
> look as an option but rather to doc it only.
>
> is not because of the fact above.
> There should not be any warning in your bug use case - master 5.0 -
> because we are going to comply with the specified behavior, which says
> there is no set insert_id hint for a trigger of sf() in the following query.
>
agreed
> You said that there is the same issue with incorrect set insert_id on
> master 5.1.x, x < 12. In such case the warning has to be issued.
> We could possibly narrow the number of exranous warnings with doing a
> test if the entire statement has write-looked at least one auto-inc
> table; condider the lines of bug#19630 fix
I find out that master 5.1.x (x<12) behaves the same as 5.0.x, it will
not log the AUTO_INCREMENT value generated by triggers/functions, and at
the sametime, it is ignored on slave by triggers/functions. So my point
is update the document to reflect this, and do not issue a warning too.
>
> + if (!table->placeholder() && !table->schema_table &&
> + table->table->found_next_number_field &&
> + (table->lock_type >= TL_WRITE_ALLOW_WRITE))
>
> to deploy near the master version check.
> As well as there should be some counter controlling at most one
> warning per the top level statement.
>
> <jasonh> andrei:
> I don't print a warning in
> rpl_master_bug33029, maybe this function should be named:
> rpl_master_maybe_bug33029
>
> So let's The name is up you.
>
>
> regards,
>
> Andrei
