> > Ooops...I accidentally took this off list, as Kevin was nice enough > > to point out. > > > > > > >> What am I looking for? > > > > >Outliers. > > > > > Yeah. It's just those 2. I'd assume that the db I created > > > yesterday would be an outlier, but template0 has been there all > > > along (of course) and is still listed as 648, a significantly > > > smaller number. > > > > > > >> The output shows me 345 rows, most of which are 132xxxxx numbers. > > >> Two of them (template0 and a database created yesterday) say 648. > > > > >The template0 database is what's keeping the clog files from being > > >cleaned up, but I guess the big question is why you care. They will > > >go away eventually, and shouldn't affect performance. Are they > > >taking enough space to merit extraordinary effort to clean them up? > > > -Kevin > > > > > > My concern is that when we had a failure a few years ago, and one of > > the clog files went bad. I had to manually recreate some customer > > data after bringing up the previous backup. So, I'd rather have them > > not there, because, well, if there are 200 of them in the dir, > > there's a higher chance in a case of a crash that one goes bad than > > if I have 15. > > > > Would adding -f (full) clean these up? I seem to recall it did in > > earlier versions. I've added the -F to it already, and that didn't > > seem to help. > > > > If you have hardware problems like that you have way more problems. > You could have corruption (silent) occurring in any of the other > database files. Good luck. I am, in fact, aware of that, but every single machine ever manufactured will have hardware problems such at this at some point. It stems quite simply from Ohm's Law, one gross over-simplification of which is as simple as "if it's got a resistor in it, it's going to fail at some point", as I'm sure you know. It's merely a matter of whether proactive replacement, backups, standby systems, etc ameliorate that risk. When we had our failure a couple of years ago, it did not. Regardless, my question still stands, and I do, in fact, care about ANY database blocking cleanup of clogs (or anything else). There's this concept of "if this then what else," and if template0 (or anyone else) is blocking that ability to properly clean those up, what else is possibly screwed up in a similar fashion. So, what can I do to resolve this issue? -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
