From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthew Wakeling <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Disc space usage
Date: Wed, 08 Oct 2008 10:01:05 -0400
Message-ID: <28838.1223474465@sss.pgh.pa.us> (raw)
In-Reply-To: <alpine.DEB.1.10.0810081443260.15851@aragorn.flymine.org>
References: <alpine.DEB.1.10.0810081238380.15851@aragorn.flymine.org>
<27956.1223471810@sss.pgh.pa.us>
<alpine.DEB.1.10.0810081443260.15851@aragorn.flymine.org>
Matthew Wakeling <matthew@flymine.org> 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 shouldn't need to --- there shouldn't be any
buffers representing such files.
>> What PG version is this, anyway?
> Postgres 8.3.0
You should consider an update to 8.3.4. A quick look in the post-8.3.0
CVS logs shows a couple of possibly relevant fixes:
2008-04-18 13:05 tgl
* src/: backend/commands/dbcommands.c, include/port.h,
port/dirmod.c (REL8_3_STABLE): Fix rmtree() so that it keeps going
after failure to remove any individual file; the idea is that we
should clean up as much as we can, even if there's some problem
removing one file. Make the error messages a bit less misleading,
too. In passing, const-ify function arguments.
2008-04-16 19:59 tgl
* src/: backend/access/nbtree/nbtree.c,
backend/access/nbtree/nbtutils.c, backend/access/transam/xlog.c,
backend/commands/dbcommands.c, backend/port/ipc_test.c,
backend/storage/ipc/ipc.c, include/access/nbtree.h,
include/storage/ipc.h, include/utils/elog.h (REL8_3_STABLE): Repair
two places where SIGTERM exit could leave shared memory state
corrupted. (Neither is very important if SIGTERM is used to shut
down the whole database cluster together, but there's a problem if
someone tries to SIGTERM individual backends.) To do this,
introduce new infrastructure macros
PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP that take care
of transiently pushing an on_shmem_exit cleanup hook. Also use
this method for createdb cleanup --- that wasn't a
shared-memory-corruption problem, but SIGTERM abort of createdb
could leave orphaned files lying around.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, matthew@flymine.org
Subject: Re: Disc space usage
In-Reply-To: <28838.1223474465@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox