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 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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Reply via email to