Bug #36991 falcon_max_transaction_backlog has no effect
Submitted: 26 May 2008 19:42 Modified: 8 Jan 2009 10:23
Reporter: Philip Stoev Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version:6.0-falcon-team OS:Any
Assigned to: Lars-Erik Bjørk CPU Architecture:Any
Triage: D4 (Minor)

[26 May 2008 19:42] Philip Stoev
Description:
The falcon_max_transaction_backlog appears to have no effect. When set to 1, SELECT * FROM INFORMATION_SCHEMA.FALCON_TRANSACTIONS continues to show more than 1 transaction in state = 'active'

How to repeat:
1. SET GLOBAL falcon_max_transaction_backlog = 1;
2. Run some transactional workload;
3. Observe no serialization, observe that I_S continues to show multiple active transactions.
[26 May 2008 20:08] Kevin Lewis
The falcon_max_transaction_backlog is not meant to limit concurrency on teh front end.  It is ment to limit the throughput int the middle where transactions that commit are processed by the gopher threads.  When it was added, there was only on gopher thread and it was intended to limit the front end from over working the middle so that the lists of deferred indexes become to long and everything starts to slow down.  

Now, however, we have a herd of gophers which keep up with the client threads very well.

In fact I would recommend changing this bug to "falcon_max_transaction_backlog is not needed."

Waiting for confirmation from Jim Starkey.
[26 Jun 2008 14:17] Lars-Erik Bjørk
Have we come to any conclusion on this?
[26 Jun 2008 14:22] Ann Harrison
falcon_max_transaction_backlog was a debugging aid for a 
problem that has been corrected by adding gopher threads.
It should be removed.
[26 Jun 2008 15:03] Lars-Erik Bjørk
Then I'll go ahead and close it with the hopes that we can reopen it if needed. If there are now objections within the time it takes me to prepare and eat my Norwegian fish-dinner, I will close it.
[26 Jun 2008 15:06] Lars-Erik Bjørk
Of course I dont't mean close it... I mean that I'll remove it... Too late in the afternoon, I guess. Maybe I should postpone removing it until the morning :)
[27 Jun 2008 4:19] Kevin Lewis
I would like to suggest that you do not delete the actual limit of serial log transactions that can be committed and not yet handled by the gopher thread(s) and that you make it a hard coded value.  I would recommend 1000 instead of the current default of 150.  That is a very conservative amount according to Jim Starkey who believes this to be an acceptable alternative to having no limit at all.  Enforcing this limit would keep the Falcon engine from 'burying itself'.  If it gets that far behind, something is really wrong, and it is probably best to refuse new work until it is resolved.
[3 Jul 2008 11:04] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/48955

2723 lars-erik.bjork@sun.com	2008-07-03
      bug#36991 falcon_max_transaction_backlog has no effect
      
      I have changed the maxTransactionBacklog to 1000 and have made the value unconfigurable.
[3 Jul 2008 11:24] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/48956

2723 lars-erik.bjork@sun.com	2008-07-03
      bug#36991 falcon_max_transaction_backlog has no effect
      
      I have changed the maxTransactionBacklog to 1000 and have made the value
      unconfigurable.
[22 Aug 2008 19:38] Kevin Lewis
This fix is in version 6.0.6
[8 Jan 2009 10:23] MC Brown
A note has been added to the 6.0.6 changelog: 

The falcon_max_transaction_backlog has been removed. The option was originally introduced to ensure that the backlog of transactions did not exceed a certain level with the gopher thread. FALCON now uses multiple gopher threads. The transaction backlog is handled internally by FALCON