~pbxt-engineers/pbxt/stable

« back to all changes in this revision

Viewing changes to src/ha_pbxt.cc

  • Committer: Paul McCullagh
  • Date: 2010-02-02 10:06:03 UTC
  • Revision ID: paul.mccullagh@primebase.org-20100202100603-3l4xe7gc5yvo9tds
Fixed bug #513012: On a table with a trigger the same record is updated more than once in one statement

Show diffs side-by-side

added added

removed removed

Lines of Context:
2466
2466
                        self->st_abort_trans = FALSE;
2467
2467
                        self->st_stat_ended = FALSE;
2468
2468
                        self->st_stat_trans = FALSE;
2469
 
                        self->st_is_update = FALSE;
 
2469
                        self->st_is_update = NULL;
2470
2470
                        if (!xt_xn_begin(self)) {
2471
2471
                                xt_spinlock_unlock(&tab->tab_ainc_lock);
2472
2472
                                xt_throw(self);
2706
2706
                 * and if it gets dup-key error it tries UPDATE, so the same row can be overwriten multiple 
2707
2707
                 * times within the same statement
2708
2708
                 */
2709
 
                if (err == HA_ERR_FOUND_DUPP_KEY && pb_open_tab->ot_thread->st_is_update)
2710
 
                        pb_open_tab->ot_thread->st_update_id++;
 
2709
                if (err == HA_ERR_FOUND_DUPP_KEY && pb_open_tab->ot_thread->st_is_update) {
 
2710
                        /* Pop the update stack: */
 
2711
                        //pb_open_tab->ot_thread->st_update_id++;
 
2712
                        XTOpenTablePtr curr = pb_open_tab->ot_thread->st_is_update;
 
2713
 
 
2714
                        pb_open_tab->ot_thread->st_is_update = curr->ot_prev_update;
 
2715
                        curr->ot_prev_update = NULL;
 
2716
                }
2711
2717
        }
2712
2718
 
2713
2719
        done:
2775
2781
 
2776
2782
        xt_xlog_check_long_writer(self);
2777
2783
 
2778
 
        if (!self->st_is_update) {
2779
 
                self->st_is_update = TRUE;
2780
 
                self->st_update_id++;
 
2784
        /* {UPDATE-STACK} */
 
2785
        if (self->st_is_update != pb_open_tab) {
 
2786
                /* Push the update stack: */
 
2787
                pb_open_tab->ot_prev_update = self->st_is_update;
 
2788
                self->st_is_update = pb_open_tab;
 
2789
                pb_open_tab->ot_update_id++;
2781
2790
        }
2782
2791
 
2783
2792
        if (table->timestamp_field_type & TIMESTAMP_AUTO_SET_ON_UPDATE)
4658
4667
                        cont_(b);
4659
4668
                }
4660
4669
 
4661
 
                /* See {IS-UPDATE-STAT} */
4662
 
                self->st_is_update = FALSE;
 
4670
                /* See {IS-UPDATE-STAT} nad {UPDATE-STACK} */
 
4671
                self->st_is_update = NULL;
4663
4672
 
4664
4673
                /* Auto begin a transaction (if one is not already running): */
4665
4674
                if (!self->st_xact_data) {
4891
4900
         * are nested within an open close of the select t1
4892
4901
         * statement.
4893
4902
         */
4894
 
        self->st_is_update = FALSE;
 
4903
        /* {UPDATE-STACK}
 
4904
         * Add to this I add the following:
 
4905
         * A trigger in the middle of an update also causes nested
 
4906
         * statements. If I reset st_is_update, then then
 
4907
         * when the trigger returns the system thinks we
 
4908
         * are in a different update statement, and may
 
4909
         * update the same row again.
 
4910
         */
 
4911
        if (self->st_is_update == pb_open_tab) {
 
4912
                /* Pop the update stack: */
 
4913
                XTOpenTablePtr curr = pb_open_tab->ot_thread->st_is_update;
 
4914
 
 
4915
                pb_open_tab->ot_thread->st_is_update = curr->ot_prev_update;
 
4916
                curr->ot_prev_update = NULL;
 
4917
        }
4895
4918
 
4896
4919
        /* See comment {START-TRANS} */
4897
4920
        if (!self->st_xact_data) {