Perhaps you had a long-running transaction open (probably a buggy or hung application) that was preventing dead rows from being cleaned up. Restarting PG closed the offending connection and rolled back the transaction, which allowed vacuum to clean up all the dead rows. If you're not running regular VACUUMs at all but are instead exclusively running VACUUM FULL, then I don't think you would see warnings about running out of fsm enties, which would explain why you did not notice the bloat. I haven't confirmed that though, so I might be wrong. -- Mark Lewis On Thu, 2007-08-30 at 11:50 +0200, Ruben Rubio wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Hi ... > > Seems its solved. But the problem is not found. > > As you may know, I do a vacuum full and a reindex database each day. I > have logs that confirm that its done and I can check that everything was > fine. > > So, this morning, I stopped the website, I stopped database, started it > again. (I was around 200 days without restarting), then I vacuum > database and reindex it (Same command as everyday) . Restart again, and > run again the website. > > Now seems its working fine. But I really does not know where is the > problem. Seems vacuum its not working fine? Maybe database should need > a restart? I really don't know. > > Does someone had a similar problem? > > Thanks in advance, > Ruben Rubio > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFG1pLMIo1XmbAXRboRAqgQAKCkWcZYE8RDppEVI485wDLnIW2SfQCfV+Hj > e8PurQb2TOSYDPW545AJ83c= > =dQgM > -----END PGP SIGNATURE----- > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org ---------------------------(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
