When working with multiple databases and the db_set_active('example'); function it is possible to kill Drupal.

The problem occurs when an error in a script causes the watchdog.module to write the error to the log. If the current active database is not the standard drupal one everything breaks.

watchdog.module needs to activate the default database before writing to the log - just to be safe.

db_set_active('default');

Comments

igy-1’s picture

igy-1 commented
Version: 4.6.0 »

I've also encountered this, is there any way to stop it?

(and then if possible return to the database that was active prior to the watchdog call?)

I've created a watchdog table in the other database, hoping that would solve the problem
I'm using a BEGIN; UPDATE; COMMIT; in pgsql
If the UPDATE fails, watchdog is called, but it fails to write to the database because pgsql won't allow another query to be run after the erorr, until ROLLBACK or COMMIT is issued...

Any ideas?

killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Active » Fixed

I don't think that adding a switch back to the default db in watchodg() is a good idea. I suggest that you add a custom error handler for what you are doing with the other db. If you want the error to be in the watchdog table, swithc back to it in your custom handler.

igy-1’s picture

igy-1 commented

So how would I achieve this?
is it possible to prevent db_query from calling watchdog() when an error occurs? (perhaps calling a custom error handler)?
Or were you saying I should use native database functions and trap the errors myself?

(thanks, by the way)

budda’s picture

budda
Primary language English
Location Cheshire
commented

db_query() in itself does not call watchdog() direct. Watchdog is a general error handler for Drupal.

However I don't think a custom error handler is a total solution. The problem is a little more global than the original bug I posted.

All of Drupal's database layer access doesn't gracefully fail - if the database cannot be connected to - PHP errors are dumped to the browser, everything just dies. This is to be expected as everything lives in the Drupal databases.

I think a catch all for database troubles would be suitable for inclusion in core. So if the database server crashes or the connection string is not correct, Drupal could show a "site off line" style generic message, rather than just dieing on it's feet.

I still think watchdog.module should handle the switching back to the default database to store it's error log records should be handled in core too - rather than forcing modules to handle their second dbase errors by themselves when Drupal has a more than capable system in place.

Is there any big overhead in calling the db_set_active() is the connection is already to the same dbase? Looking at http://drupaldocs.org/api/4.6/function/db_set_active I would assume not, as the connection is stored in a static array.

Anonymous’s picture

(not verified) commented
kmr2005’s picture

kmr2005 commented
Anonymous’s picture

(not verified) commented
pem’s picture

pem commented
Status: Fixed » Closed (fixed)
Chris Johnson’s picture

Chris Johnson commented
Version: » 4.6.5

See issue 42000.