Hello,
It turns out the previous explanation was WRONG.
Here is another stab at the problem. My understanding of the savepoint
initialization process is:
1. the handlerton sets its savepoint_offset to the size of its local
savepoint data.
2. the ha_initailize_handlerton function reads it, modifies its idea of the
total savepoint data size, and sets it to the offset of the handlerton's
local state
If this is correct, then why does the ha_initialize_handlerton function do
step (2) twice? It looks like a code merge bug to me.
Rich Prohaska
On Mon, Jul 9, 2012 at 4:41 PM, Rich Prohaska <prohaska@xxxxxxxxxxx> wrote:
Hello,
We observed a problem with savepoints in Mariadb 5.5.25. The problem at
the SQL layer is that a "rollback to savepoint" statement would get an error
after the savepoint was created. The problem was caused by the savepoint
name in the savepoint stack getting overwritten by the handlerton
savepoint_set method.
Here is what we think is going on:
1. space is reserved in the savepoint memory for each handlerton in the
ha_initialize_handlerton function.
2. then space is reserved for the SAVEPOINT object in ha_init. (Yes,
ha_init gets called AFTER the ha_initialize_handlerton calls.
3. ha_savepoint computes the address of the handlerton's object as
(uchar*)(sv+1) + ht->savepoint_offset. this assumes that the SAVEPOINT
object is laid out first, followed by the handlerton's space.
unfortunately, step (1) occurs before step (2) so this is not the case.
Here is a possible fix:
Move the base initialization of the savepoint_alloc_size from ha_init to
the global intiializer. With this change, the handlerton's offsets are
computed AFTER the SAVEPOINT space is reserved.
Is this correct?
Thanks
Rich Prohaska
