Bug #61248 Drop of stored function executed in an open transaction will break replication

• Submitted: 20 May 2011 17:32
• Modified: 21 Jun 2011 14:16
• Reporter: Erik Jones
• Status: No Feedback
• Category: MySQL Server: Replication
• Severity: S2 (Serious)
• OS: Any
• CPU Architecture: Any

[20 May 2011 17:32] Erik Jones

Description:
When, on a master db, if you open a transaction, execute a stored function, and then drop that function in another session before the first is committed replication on any replicas will break since they will get the DROP FUNCTION before the transaction that used it.

I understand that this behavior is inherent in the fact that dropping stored functions amounts to removing rows from tables in the mysql schema and no locks are taken out on those tables when stored functions are executed (that would be worse).  However, this should definitely be considered a replication "gotcha" and documented in the manual's "Replication Features and Issues" section.

How to repeat:
1. Create a stored function

2. In a session, open a transaction and execute the function.  Do not commit.

3. In another session, drop the stored function.

4. Commit the transaction started in 2 above.

Since the DROP FUNCTION executed in step 3 gets written to the binlog before the transaction that used it, replication on any replicas will then break when they execute the transaction started in step 2 since the function will not be there.

Suggested fix:
Document this behavior.

[21 May 2011 14:16] Valeriy Kravchuk

What exact server version, x.y.z, do you use on master?

[21 Jun 2011 23:00] Bugs System

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".