Last modified: 2012-08-04 20:48:49 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 20475 - SpecialExport producing corrupt output (PostgreSQL errors)
SpecialExport producing corrupt output (PostgreSQL errors)
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Export/Import (Other open bugs)
1.16.x
All All
: Normal major (vote)
: ---
Assigned To: Greg Sabino Mullane
:
Depends on:
Blocks: postgres
  Show dependency treegraph
 
Reported: 2009-09-02 19:31 UTC by OverlordQ
Modified: 2012-08-04 20:48 UTC (History)
2 users (show)

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


Attachments

Description OverlordQ 2009-09-02 19:31:03 UTC
If using a Postgres back end when you go to export any pages it returns corrupted XML with the following at the end:

==
<b>Warning</b>:  pg_query(): 50 is not a valid PostgreSQL link resource in <b>/var/www/mysite/wiki/includes/db/DatabasePostgres.php</b> on line <b>582</b><br />

<br />
<b>Warning</b>:  pg_last_error() [<a href='function.pg-last-error'>function.pg-last-error</a>]: No PostgreSQL link opened yet in <b>/var/www/mysite/wiki/includes/db/DatabasePostgres.php</b> on line <b>666</b><br />
<br />
<b>Warning</b>:  pg_last_error() [<a href='function.pg-last-error'>function.pg-last-error</a>]: No PostgreSQL link opened yet in <b>/var/www/mysite/wiki/includes/db/DatabasePostgres.php</b> on line <b>673</b><br />

<br />
<b>Warning</b>:  pg_query(): 50 is not a valid PostgreSQL link resource in <b>/var/www/mysite/wiki/includes/db/DatabasePostgres.php</b> on line <b>582</b><br />
<br />
<b>Warning</b>:  pg_last_error() [<a href='function.pg-last-error'>function.pg-last-error</a>]: No PostgreSQL link opened yet in <b>/var/www/mysite/wiki/includes/db/DatabasePostgres.php</b> on line <b>666</b><br />

<br />
<b>Warning</b>:  pg_last_error() [<a href='function.pg-last-error'>function.pg-last-error</a>]: No PostgreSQL link opened yet in <b>/var/www/mysite/wiki/includes/db/DatabasePostgres.php</b> on line <b>673</b><br />
==

From what I can tell this is error is generated when the job queue is tried to run:

==
/wiki/index.php?title=Special:Export&action=submit   Exception from line 1041 of /var/www/mysite/wiki/includes/db/DatabasePostgres.php: A database error has occurred
Query: SELECT  *  FROM job  WHERE job_id >= 0  ORDER BY job_id LIMIT 1
Function: Job::pop
Error: 0
SQL ERROR (ignored):
==

commenting out $lb->closeAll(); on line 275 of SpecialExport fixes this error, but as I have no clue of the LoadBalancer magic I don't know what effects this cause.
Comment 1 Brion Vibber 2009-09-03 01:00:08 UTC
Greg, can you take a look at this? Sounds like too many connections are getting closed out...

For full-history exports, we open a second connection to run unbuffered queries, via a newly created DB load balancer object. It sounds like when we close out the second connection, we're also closing out the first one (perhaps we're ending up with the main LB instead of a new one, or the second connection is just aliasing to the first one instead of actually creating a new one.)
Comment 2 OverlordQ 2009-10-14 04:08:46 UTC
This might be fixed (somehow), exporting with r57697 does not trigger this warning anymore.

Will poke at it more before marking resolved.
Comment 3 OverlordQ 2009-10-14 18:10:33 UTC
I got it again, and after further testing I believe it is the last case you mentioned. I'm using a single DB setup and as per the PHP docs:

==
If a second call is made to pg_connect() with the same connection_string  as an existing connection, the existing connection will be returned unless you pass PGSQL_CONNECT_FORCE_NEW as connect_type .
==

So when the LB goes to create a new connection it gets the same connection string and thus reuses the connection, then when the supposed duplicate LB closes out it's connection and calls pg_close, it unknowingly kills the shared connection.
Comment 4 Sumana Harihareswara 2011-11-02 21:50:41 UTC
Andy Lester tried to reproduce this on a similar system today and couldn't, so I'm closing with the could-not-reproduce resolution.  If you can still reproduce it, please reopen and let us know.

Relevant IRC conversation:

    <G_SabinoMullane> I think OverlordQ summed it up well. Yet more fun with the loadbalancer
    <alester> One of the unfortunate aspects of pg_query() is that it doesn't require a first parameter of a connection if it's been called before. It lets you call pg_query( $conn, $sql ) the first time , and then pg_query( $sql ) thereafter.  and I'm guessing that somewhere before 1.17.0 which I'm looking at now, there were pg_query() calls that relied ont hat behavior incorrectly. Anyway, I'm looking in DatabasePostgres.php and I don't see anywhere it's calling pg_query() without a connection object.
    <G_SabinoMullane> It's pg_connect() that's the issue, no?
    <alester> But I don't have the 1.16-svn source in front of me.
    (to repro on MediaWiki 1.17.0): <Nikerabbit> it should be easy to test, make some jobs and make sure they are run after call to Special:Export
    <Nikerabbit> alester: you should also have non-zero jobqueue
    <G_SabinoMullane> I've exported pages just fine before (but never tried to specifically duplicate this bug)
    <MaxSem> Nikerabbit, I have: Notice: unserialize() [function.unserialize]: Error at offset 0 of 53 bytes in D:\Projects\MediaWiki\includes\objectcache\SqlBagOStuff.php on line 381
    <alester> I just now ran an export on all the pages in [[Category:Development]] on my company wiki and it ran fine w/o errors.
    <Nikerabbit> I wouldn't be surprised if it is really fixed, it's been many changes since 2009

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


Navigation
Links