Bug #14066 Bad behaviour when using excessive value for --binlog_rows_event_max_size
Submitted: 17 Oct 2005 8:09 Modified: 10 May 2006 20:23
Reporter: Mats Kindahl Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.1 OS:Any (ALL)
Assigned to: Mats Kindahl CPU Architecture:Any

[17 Oct 2005 8:09] Mats Kindahl
The --binlog_row_events_max_size option is used to decide the breaking point when a RBR event should be flushed to the binary log.  In addition, to prevent excessive allocation *calls*, the value is used to allocate an appropriate buffer immediately.  The default value of the option is 1024.

Suppose that the user sets a very large value, say 256MB, in an attempt to send as many rows as possible in one event.  Then the ``malloc()`` used internally will allocate an excessive amount of
memory, when the normal case is to use a much smaller amount.

How to repeat:
Call mysqld with --binlog_row_events_max_size=4000000000 and see what happens.

Suggested fix:
Allocate a smaller portion initially, and double the amount of memory
whenever more is needed.  To prevent an excessive number of calls to
``malloc()``, the memory does not need to be allocated each time a RBR
event is constructed, but rather a buffer could be reused.

The problems with this solution are:

- If a really large RBR event is allocated, the buffer will grow to a
  large amount and take up memory in the server.  If these big chunks
  are rare, the server will keep a very large buffer allocated
[10 May 2006 20:23] Mats Kindahl
This item was fixed with the patch for implementing WL#3023 (changset 1.2048.3.3 dated 2006-02-16).