https://bugzilla.wikimedia.org/show_bug.cgi?id=44136

--- Comment #4 from OverlordQ <[email protected]> ---
Alright, I think I know the issue. 

On line 817 of DatabasePostgres[1] we explicitly call $savepoint->commit() if
we have a savepoint, 

SavepointPostgres::commit calls the commit function of the originally passed
database handle. This isn't defined IN DatabasePostgres so it uses
DatabaseBase::commit which calls DatabaseBase::doCommit which clears out the
mTrxLevel and does a 'COMMIT' query.

Then after we return on 837 of DatabasePostgres $savepoint moves out of scope
and so it's __destruct method is called.

SavepointPostgres::__destruct only checks $this->didbegin and not against
$dbw->trxLevel(). 

In the DatabasePostgres::insert function the savepoint is initialized before
the query method, and so in the context of SavepointPostgres::__construct there
is no trxLevel yes, and thus sets didbegin.

So when __destruct is called, it calls $dbw->rollback() which throws the error
that there is No transaction to rollback as DatabaseBase::commit already
committed the transaction.

tl;dr SavepointPostgres::__destruct only checks to see if we started a
transaction and not if we're still in one and tries to rollback out of
transaction.

It seems bugzilla wont let me CC saper as it's his code, so I will pester on
IRC.

1 -
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blame;f=includes/db/DatabasePostgres.php;hb=c15d0a7521231c2cb71e664265e08d0ae514fc73#l817

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to