maria-developers team mailing list archive
Mailing list archive
Re: problem with savepoints in mariadb 5.5.25
I posted our fix at lp:~prohaska7/maria/5.5-savepoint-offset-fix.
Does it make sense?
On Mon, Jul 9, 2012 at 7:17 PM, Rich Prohaska <prohaska@xxxxxxxxxxx> wrote:
> 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:
>> 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?
>> Rich Prohaska