An error occurred fetching the project authors.
  1. 04 Jan, 2006 1 commit
  2. 22 Dec, 2005 1 commit
  3. 17 Nov, 2005 1 commit
  4. 10 Nov, 2005 1 commit
    • guilhem@mysql.com's avatar
      WL#2971 "change log-bin-trust-routine-creators=0 to apply only to functions". · ff46e549
      guilhem@mysql.com authored
      Indeed now that stored procedures CALL is not binlogged, but instead the invoked substatements are,
      the restrictions applied by log-bin-trust-routine-creators=0 are superfluous for procedures.
      They still need to apply to functions where function calls are written to the binlog (for example as "DO myfunc(3)").
      We rename the variable to log-bin-trust-function-creators but allow the old name until some future version (and issue a warning if old name is used).
      ff46e549
  5. 12 Oct, 2005 1 commit
  6. 01 Sep, 2005 1 commit
  7. 25 Aug, 2005 1 commit
  8. 19 Jul, 2005 1 commit
  9. 06 May, 2005 1 commit
  10. 05 May, 2005 2 commits
    • gbichot@quadita2.mysql.com's avatar
      688d9ee0
    • gbichot@quadita2.mysql.com's avatar
      Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146... · b72ae4fe
      gbichot@quadita2.mysql.com authored
        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.
      b72ae4fe