Last modified: 2012-08-04 20:48:49 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.
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.)
This might be fixed (somehow), exporting with r57697 does not trigger this warning anymore. Will poke at it more before marking resolved.
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.
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
