Port fake changes fix for MTS from the Facebook patch

[Laurynas Biveinis]

Facebook patch has the following bit at the start of row_ins_sec_index_entry_by_modify():

    /* Another exception here is when sql thread updates the delete
    marked node and unmarks it before the faker thread got here.
    This can happen with multi threaded slave and when faker thread
    tries to update the same secondary index node as that of sql slave
    worker. */
    trx_t* trx=thr_get_trx(thr);
    if (trx->fake_changes)
      return(DB_SUCCESS);

It does not have a corresponding MTR testcase. Port this bit and look into creating a corresponding testcase.

[Roel Van de Paar (roel11)]

Could this be the cause of some of the fake changes bugs we've been seeing?

[Laurynas Biveinis (laurynas-biveinis)]

Yes, might be related to 1 or 2 crashes we have seen. Which is good, as non-MTS testcase is then possible.

[Krunal Bauskar (krunal-bauskar)]

From the comment is sounds like

sql-thread:
* try to update something ... causes delete-mark of the record ...

fetcher thread (running with fake-change mode-on)
* try to update same record .. found that the record is delete mark and so opt for row_ins_sec_index_entry_by_modify() but before it could go ahead slave thread trx is rolled back and so the delete-marked record is reset back to non-delete-marked.

* When the row_ins_sec_index_entry_by_modify() .. resumes things will crash as record is not more delete-marked.

---------

How is this protected in normal mode:
- Any other thread running in normal mode will have to wait for first sql-thread to release latch. sql-thread takes X-LATCH on the leaf page if mode = BTR_MODIFY_LEAF.

Said that even the faker-thread should be waiting to get S-LATCH if other sql-thread is holding X-latch so I couldn't understand the scenario. May be some other scenario exist.

[Krunal Bauskar (krunal-bauskar)]

There is no TC attached. Patch comment doesn't help understand what scenario is possible.
May be if we get to see a scenario we can re-open this but we don't see any such possibility.
Also, related bug in this area are fixed. If that is what this patch was trying to address but then patch look a real short-cut to address that scenario.

[Launchpad Janitor (janitor)]

[Expired for Percona Server 5.6 because there has been no activity for 60 days.]

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1402