Hello

It seems that in a postgres 8.4+ setup there is a race condition that breaks the variables caching during bootstrap. It seems to be specific to one site but it is not dependent on web or postgres server setup (i tried troubleshooting that).
Also see http://drupal.org/node/794286 from another user.

The attached patch fixes this (tested with 6.20 and 6.HEAD). Essentially the cache patch asks that the db_lock is done during caching (weird that it wasn't before?). Determining whether this is a deeper problem with the database system (bug http://drupal.org/node/794286) would require someone more experienced that me.

Not fixing this cache bug results in the postgres reporting as http://drupal.org/node/794286 to the log file, quickly filling up the disk (gigabytes of data per day).

thanks
alexie

CommentFileSizeAuthor
cache.patch637 bytesalpapan

Comments

Status: Needs review » Needs work

The last submitted patch, cache.patch, failed testing.

alpapan’s picture

alpapan commented
Status: Needs work » Needs review

cache.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, cache.patch, failed testing.

drupdan3’s picture

drupdan3 commented

I see the same problem in 7.10 (also with PostgreSQL 8.4)

damien tournoud’s picture

damien tournoud commented
Status: Needs work » Closed (works as designed)

That's by design. In case of a race condition, the INSERT query can fail, that's why errors are suppressed. Disable logging of those kind of application errors on the PostgreSQL side.