Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id DAFD237BA4A for ; Wed, 8 Oct 2008 12:51:35 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 67435-08 for ; Wed, 8 Oct 2008 12:51:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 6728A37B9FD for ; Wed, 8 Oct 2008 12:51:32 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m98FpSZ1008828; Wed, 8 Oct 2008 11:51:28 -0400 (EDT) To: Matthew Wakeling cc: pgsql-performance@postgresql.org Subject: Re: Disc space usage In-reply-to: References: <27956.1223471810@sss.pgh.pa.us> <29539.1223476681@sss.pgh.pa.us> Comments: In-reply-to Matthew Wakeling message dated "Wed, 08 Oct 2008 16:38:10 +0100" Date: Wed, 08 Oct 2008 11:51:27 -0400 Message-ID: <8827.1223481087@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/41 X-Sequence-Number: 31622 Matthew Wakeling 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 of the failures, which were a while back. > However, I have now altered the script so that it fails with a message > saying "Report this to Matthew", so if it happens again I'll be able to > give you some more detail. 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 to copy the DB, which is probably not trivial for the DB sizes you're dealing with). If you could also correlate that to the times you saw CREATE failures then it'd be pretty convincing that we know failed CREATEs are the issue. Also, I would definitely urge you to update to 8.3.4. Although I'm not seeing a mechanism for CREATE to fail to clean up like this, I'm looking at the 8.3 branch tip code, not 8.3.0 ... regards, tom lane