Because on PostgreSQL db_lock_table() starts a transaction, calls to watchdog() that are routed to the dblog module do not get inserted into the watchdog table until the conclusion of the transaction, which happens at db_unlock_tables(). Because the transaction can fail (due to a SQL error, for instance), there's a very real possibility of watchdog data loss in this situation.

For instance, if a database query following db_lock_table() failed, and that failure was to be logged to watchdog() by core, because the transaction has already failed, the administrator would never find out about the failed query because it would never be inserted.

I've had a look at Drupal 7 and initially it looks like the same issue applies there too. Database::getConnection('default', 'default') will just return the existing connection that's within the transaction context.

The fix for this needs to be that watchdog uses a different connection to the database to log watchdog messages if the database is inside a transaction. I'm not entirely sure how you'd detect this in D6 though, so maybe it should always open a secondary connection for watchdog messages?

I'm happy to have a go at a patch for D6 and test case for D7 for this.

Comments

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.