maria-developers team mailing list archive

[Rich Prohaska <prohaska@xxxxxxxxxxx>]

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
>
>