Last modified: 2013-12-06 18:22:15 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27283 - SqlBagOStuff breaks PostgreSQL transactions
SqlBagOStuff breaks PostgreSQL transactions
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.21.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: postgres
  Show dependency treegraph
 
Reported: 2011-02-09 19:09 UTC by Mark A. Hershberger
Modified: 2013-12-06 18:22 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
section of log with errors and such (5.25 KB, text/plain)
2012-03-19 01:29 UTC, Mark A. Hershberger
Details
section of log with errors and such (4.80 KB, text/plain)
2012-03-19 01:33 UTC, Mark A. Hershberger
Details
importdump fix (703 bytes, patch)
2012-03-19 12:12 UTC, Mark A. Hershberger
Details
start of debug log with messed up transaction (3.61 KB, text/plain)
2012-03-19 18:10 UTC, Mark A. Hershberger
Details

Description Mark A. Hershberger 2011-02-09 19:09:49 UTC
Got a few "WARNING:  there is already a transaction in progress" which shows that a BEGIN was given without ending the previous transaction.  Excerpt from the logs:


2011-02-09 13:07:13 EST LOG:  statement: BEGIN
2011-02-09 13:07:13 EST LOG:  statement: SELECT /* User::idFromName  */  user_id  FROM mwuser  WHERE user_name = 'Graham87'  LIMIT 1  
2011-02-09 13:07:13 EST LOG:  statement: SELECT /* LinkCache::addLinkObj  */  page_id,page_len,page_is_redirect,page_latest  FROM page  WHERE page_namespace = '0' AND page_title = 'Analysis_of_var
iance/Degrees_of_freedom'  LIMIT 1  
2011-02-09 13:07:13 EST LOG:  statement: SELECT /*   */ nextval('page_page_id_seq')
2011-02-09 13:07:13 EST LOG:  statement: SAVEPOINT mw
2011-02-09 13:07:13 EST LOG:  statement: INSERT /* Article::insertOn  */ INTO page (page_id,page_namespace,page_title,page_counter,page_restrictions,page_is_redirect,page_is_new,page_random,page_touched,page_latest,page_len) VALUES ('438','0','Analysis_of_variance/Degrees_of_freedom','0','','0','1','0.708513577845','2011-02-09 18:07:13 GMT','0','0')
2011-02-09 13:07:13 EST LOG:  statement: BEGIN
2011-02-09 13:07:13 EST WARNING:  there is already a transaction in progress
2011-02-09 13:07:13 EST LOG:  statement: DELETE /* SqlBagOStuff::set 127.0.0.1 */ FROM objectcache WHERE (keyname='my_wiki:pcache:idhash:438-0!*!0!!*!*!*')
Comment 1 Brion Vibber 2011-02-12 03:32:52 UTC
I don't think they nest in MySQL either, so this likely exposes general bugs.
Comment 2 Greg Sabino Mullane 2011-03-21 19:56:44 UTC
This should be easy enough to trap in the begin() method, no? I saw *tons* of these in 1.15, but it's gotten much better in 1.16 and on.
Comment 3 Mark A. Hershberger 2011-12-27 15:35:16 UTC
This problem probably led to bug #32351
Comment 4 Mark A. Hershberger 2011-12-27 15:35:51 UTC
I mean Bug #32551
Comment 5 Platonides 2011-12-27 19:57:26 UTC
However, on some places
Comment 6 Marcin Cieślak 2012-03-14 22:41:48 UTC
This probably happens every time we do MySQL's "REPLACE" or "INSERT IGNORE".
We fake them using an extra savepoint; unfortunately there are problems with proper rollback.

Can you check if r113534 fixes this (it's actually a whole series starting with r113408, sorry for the mess).

Please enable 

$wgDebugDBTransactions  = true;

to see transaction state transitions.
Comment 7 Mark A. Hershberger 2012-03-19 01:29:00 UTC
Created attachment 10262 [details]
section of log with errors and such

I'm still getting a number of errors in the pg log when I have

  log_min_error_statement = error
  log_min_duration_statement = 0
  log_error_verbosity = verbose

in my postgresql.conf
Comment 8 Mark A. Hershberger 2012-03-19 01:33:37 UTC
Created attachment 10263 [details]
section of log with errors and such

Better section of the logs
Comment 9 Mark A. Hershberger 2012-03-19 04:46:04 UTC
Setting

  $wgMainCacheType    = CACHE_MEMCACHED;

keeps SqlBagOStuff from being used which is where a lot of the messages come from.
Comment 10 Mark A. Hershberger 2012-03-19 12:12:42 UTC
Created attachment 10271 [details]
importdump fix

Another place that causes problems is "INSERT IGNORE" handling for Pg.  In importDump.php, this happens with category count updates.  The attached patch fixes this, but probably in a not very good way.
Comment 11 Marcin Cieślak 2012-03-19 14:58:57 UTC
Yeah, if we are not in a transaction, this is a race condition.

Are you using trunk? Are you getting

Transaction state changed from 

in the debug log?

Which dump are trying to load?
Comment 12 Mark A. Hershberger 2012-03-19 17:28:26 UTC
(In reply to comment #11)
> Yeah, if we are not in a transaction, this is a race condition.

Exactly. :)

> Are you using trunk?

Yes.

> Are you getting
> 
> Transaction state changed from 
> 
> in the debug log?

Let me enable the debug log and re-try.

> Which dump are trying to load?

I was using zhwiki which was fun, but made testing a little to difficult.  I've been using simplewiki since.
Comment 13 Mark A. Hershberger 2012-03-19 18:10:21 UTC
Created attachment 10274 [details]
start of debug log with messed up transaction

Another problems happens once right at the beginning of every import:

 BEGIN
   SELECT -- LCStore_DB::get
*  BEGIN  -- fails
   DELETE -- LCStore_DB::startWrite
   INSERT -- LCStore_DB::set
...

(In reply to comment #11)
> Are you getting
> 
> Transaction state changed from 
> 
> in the debug log?

Attaching the bit of the log that covers this section above.
Comment 14 Mark A. Hershberger 2012-03-19 18:21:19 UTC
And, as suspected, setting

  $wgCacheDirectory = "$IP/cache";

got rid of the problem with found in comment #13 -- which is still a real problem, of course.
Comment 15 Marcin Cieślak 2012-03-20 15:39:01 UTC
Some relevant discussions from wikitech-l:

http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/49500

http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/39827

we cannot (possibly) have a single transaction for a whole web request, which would be the best solution, or can we?
Comment 16 Mark A. Hershberger 2012-03-20 15:55:17 UTC
Split comment #13 off to Bug #35357
Comment 17 Marcin Cieślak 2012-03-30 00:16:49 UTC
Should be fixed by Gerrit change #3962
Comment 18 Tim Landscheidt 2012-10-23 20:11:10 UTC
Has this really been fixed or was it broken again in the meantime?  I (still) see a lot of those warnings (cf. https://travis-ci.org/scfc/mediawiki/jobs/2904641):

| PHP Notice:  DatabaseBase::rollback: No transaction to rollback, something got out of sync! [Called from DatabaseBase::rollback in /home/travis/builds/scfc/mediawiki/includes/db/Database.php at line 3030] in /home/travis/builds/scfc/mediawiki/includes/debug/Debug.php on line 283

I remember some discussion about warnings on MySQL, but I don't know if and how they are related.
Comment 19 Aude 2012-12-28 23:08:54 UTC
I am seeing such errors when running various unit tests:

DatabaseBase::rollback: No transaction to rollback, something got out of sync! [Called from DatabaseBase::rollback in /var/www/common/mw-pg/includes/db/Database.php at line 3088]

/var/www/common/mw-pg/includes/debug/Debug.php:283
/var/www/common/mw-pg/includes/debug/Debug.php:144
/var/www/common/mw-pg/includes/GlobalFunctions.php:1103
/var/www/common/mw-pg/includes/db/Database.php:3088
/var/www/common/mw-pg/includes/db/DatabasePostgres.php:234
/var/www/common/mw-pg/includes/Block.php:475
/var/www/common/mw-pg/includes/Block.php:475
/var/www/common/mw-pg/tests/phpunit/includes/BlockTest.php:214
/var/www/common/mw-pg/tests/phpunit/MediaWikiTestCase.php:116
/var/www/common/mw-pg/tests/phpunit/MediaWikiPHPUnitCommand.php:60
/var/www/common/mw-pg/tests/phpunit/MediaWikiPHPUnitCommand.php:46
/var/www/common/mw-pg/tests/phpunit/phpunit.php:107
Comment 20 Aude 2012-12-28 23:10:16 UTC
not so sure this is fixed, or it's broken again :(  reopening....
Comment 21 Marcin Cieślak 2013-12-06 18:22:15 UTC
No transaction to rollback, something got out of sync!
[Called from DatabaseBase::rollback in
/var/www/common/mw-pg/includes/db/Database.php

is actually a cover-up of some other database error. This is caused by bug 58095.

Closing this case which was specific to SqlBagOfStuff.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links