Re: [PERFORM] Disc space usage

2008-10-09 Thread Matthew Wakeling
On Wed, 8 Oct 2008, Tom Lane wrote: One other bit of possibly useful data would be to eyeball the file mod times in the orphaned subdirectories. If they were from failed CREATE DATABASEs then I'd expect every file in a given directory to have the same mod time (modulo the amount of time it takes

Re: [PERFORM] Disc space usage

2008-10-08 Thread Tom Lane
Matthew Wakeling <[EMAIL PROTECTED]> writes: > Speaking to some of my colleagues, sometimes the createdb process fails > with a very specific error message. If we wait five seconds and try again, > then it succeeds. So, maybe the duff directories are from those failures. > The error message is a

Re: [PERFORM] Disc space usage

2008-10-08 Thread Tom Lane
Matthew Wakeling <[EMAIL PROTECTED]> writes: > The oid in the error message is of a database that no longer exists, which > indicates that it is *probably* referring to the template database. > Unfortunately my colleagues just wrote the script so that it retries, so > we don't have a decent log

Re: [PERFORM] Disc space usage

2008-10-08 Thread Matthew Wakeling
On Wed, 8 Oct 2008, Tom Lane wrote: Hmm, would that include dropping tables in the database you are about to copy? If so, this error is fairly readily explainable as a side effect of the delayed dropping of physical files in recent PG versions. It could quite possibly include dropping tables.

Re: [PERFORM] Disc space usage

2008-10-08 Thread Matthew Wakeling
On Wed, 8 Oct 2008, Scott Marlowe wrote: The error message is always something like this: createdb: database creation failed: ERROR: could not stat file "base/32285287/32687035": No such file or directory By any chance are you running on windows with virus protection software on the server?

Re: [PERFORM] Disc space usage

2008-10-08 Thread Scott Marlowe
On Wed, Oct 8, 2008 at 8:00 AM, Matthew Wakeling <[EMAIL PROTECTED]> wrote: > The error message is always something like this: > > createdb: database creation failed: ERROR: could not stat file > "base/32285287/32687035": No such file or directory By any chance are you running on windows with vir

Re: [PERFORM] Disc space usage

2008-10-08 Thread Tom Lane
Matthew Wakeling <[EMAIL PROTECTED]> writes: > On Wed, 8 Oct 2008, Tom Lane wrote: >> Anything under $PGDATA/base that doesn't correspond to a live row in >> pg_database is junk. > So I can delete it? Might be safer to stop the db server while I do that > though. In principle, at least, you shou

Re: [PERFORM] Disc space usage

2008-10-08 Thread Matthew Wakeling
On Wed, 8 Oct 2008, Tom Lane wrote: The interesting question is how it got that way, and in particular how you seem to have managed to have repeated instances of it. Speaking to some of my colleagues, sometimes the createdb process fails with a very specific error message. If we wait five seco

Re: [PERFORM] Disc space usage

2008-10-08 Thread Matthew Wakeling
On Wed, 8 Oct 2008, Tom Lane wrote: It appears that there are a few large directories that do not correspond to any database. I wonder if these have been left behind accidentally by Postgres. Anything under $PGDATA/base that doesn't correspond to a live row in pg_database is junk. So I can de

Re: [PERFORM] Disc space usage

2008-10-08 Thread Tom Lane
Matthew Wakeling <[EMAIL PROTECTED]> writes: > One of our build servers recently ran out of disc space while trying to > copy an entire database. This led me to investigate the database cluster, > which is stored on a RAID array with a total size of 1TB. Running a query > to list all databases a

[PERFORM] Disc space usage

2008-10-08 Thread Matthew Wakeling
One of our build servers recently ran out of disc space while trying to copy an entire database. This led me to investigate the database cluster, which is stored on a RAID array with a total size of 1TB. Running a query to list all databases and their sizes did not add up to the amount of spa