The proper way to see if any rows where matched by the WHERE clause of an UPDATE query is to use db_affected_rows(). This is what the patch does. If no rows where affected, it means that our lock is no longer in the database table and thus cannot be extended.

Seeing the same thing here when we try to extend an unexpired lock. As c960657 said, It is not proper to use db_result() on a db_query() return value when an UPDATE query is used. For MySQL systems, the result of mysql_query() where an UPDATE query is issued is simply TRUE or FALSE, not a resource as db_result() expects. FALSE only happens on error, and an UPDATE that doesn't update any rows is not an error, so the db_affected_rows() call in the supplied patch is the proper way of handling this.

From what I can tell, pg_query() returns a result resource regardless of the query type issued, so, if the locking implementation was initially written and tested against Postgres, then that may be why this wasn't caught before. We (and I'm sure most of the people using Drupal), however, use MySQL.