Sorry, I introduced this bug. ---------------------------------------------------------------------------
Tom Lane wrote: > Benjamin Minshall <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> It's sounding like what you had was just transient bloat, in which case > >> it might be useful to inquire whether anything out-of-the-ordinary had > >> been done to the database right before the excessive-CPU-usage problem > >> started. > > > I don't believe that there was any unusual activity on the server, but I > > have set up some more detailed logging to hopefully identify a pattern > > if the problem resurfaces. > > A further report led us to realize that 8.2.x in fact has a nasty bug > here: the stats collector is supposed to dump its stats to a file at > most every 500 milliseconds, but the code was actually waiting only > 500 microseconds :-(. The larger the stats file, the more obvious > this problem gets. > > If you want to patch this before 8.2.4, try this... > > Index: pgstat.c > =================================================================== > RCS file: /cvsroot/pgsql/src/backend/postmaster/pgstat.c,v > retrieving revision 1.140.2.2 > diff -c -r1.140.2.2 pgstat.c > *** pgstat.c 26 Jan 2007 20:07:01 -0000 1.140.2.2 > --- pgstat.c 1 Mar 2007 20:04:50 -0000 > *************** > *** 1689,1695 **** > /* Preset the delay between status file writes */ > MemSet(&write_timeout, 0, sizeof(struct itimerval)); > write_timeout.it_value.tv_sec = PGSTAT_STAT_INTERVAL / 1000; > ! write_timeout.it_value.tv_usec = PGSTAT_STAT_INTERVAL % 1000; > > /* > * Read in an existing statistics stats file or initialize the stats to > --- 1689,1695 ---- > /* Preset the delay between status file writes */ > MemSet(&write_timeout, 0, sizeof(struct itimerval)); > write_timeout.it_value.tv_sec = PGSTAT_STAT_INTERVAL / 1000; > ! write_timeout.it_value.tv_usec = (PGSTAT_STAT_INTERVAL % 1000) * 1000; > > /* > * Read in an existing statistics stats file or initialize the stats to > > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
