Commit graph

8 commits

Author SHA1 Message Date
bell@sanja.is.com.ua
aec371f910 WL#2787 (part 2, ver 3 (merged)) changed securety context switching 2005-09-15 22:29:07 +03:00
sergefp@mysql.com
95c3afc5d9 Fix for BUG#12335 (SP replication) : New binlogging strategy for stored PROCEDUREs/FUNCTIONs.
"Interleaved SPs execution is now binlogged properly, "SELECT spfunc()" is binlogged too.
The known remaining issue is binlogging/replication of "a routine is deleted while it is executed" scenario.
2005-08-25 17:34:34 +04:00
petr@mysql.com
4fb6f4dddf Fix for Bug#11247 Stored procedures: Function calls in long loops leak memory
and Bug#12297 SP crashes the server if data inserted inside a lon loop
Third commit attempt. With fixes to the issues, showed up after full rebuild and
tests on other hosts.
2005-08-18 11:23:54 +02:00
dlenev@mysql.com
8a3e723b74 Fix for bugs #5892/6182/8751/8758/10994 (based on Antony's patch)
"Triggers have the wrong namespace"
  "Triggers: duplicate names allowed"
  "Triggers: CREATE TRIGGER does not accept fully qualified names"
  "SHOW TRIGGERS"
2005-07-19 20:06:49 +04:00
gbichot@quadita2.mysql.com
c2ec0e7409 correcting error messages after discussion with Paul (replication of routines). 2005-06-19 17:39:08 +02:00
gbichot@quadita2.mysql.com
ea1bc59ed9 Dmitri please review. Fix for BUG#10417 "CREATE TRIGGER not written to binlog":
writing DROP and CREATE TRIGGER to binlog, disabling binlogging
of substatements, testing.
2005-05-06 18:52:19 +02:00
gbichot@quadita2.mysql.com
688d9ee03c making rpl_sp.test hostname-independent 2005-05-05 18:28:54 +02:00
gbichot@quadita2.mysql.com
b72ae4fe57 Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
  limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
  Reason I don't propagate caller info to the binlog as planned is that on master and slave
  users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00