"Philip Poles" <philip@surfen.com> writes:
> Basically, the backend has created a bunch of empty files of the name
> <table_name>.<n>, ~32500 for one table, ~50000 for another, ~44000 for
> a third, and ~250 for a fourth. From reading the old thread on this,
> I suspect it's being caused by the nightly vacuum we run, and is due
> to a corrupted index.
Probably so. The proximate cause of that behavior was that if the
low-level file access code (md.c) was handed a ridiculously large
intra-file block number, it would try to access the file segment
containing that block number --- and merrily create all the intervening
segments, though not populate them with any data. So a bad block number
is being injected from somewhere, and a corrupted index is the most
likely source.
In current sources, md.c will barf promptly if handed a block number
more than one segment beyond the current EOF, so that
sorcerer's-apprentice behavior should be fixed. The more interesting
question is whether the original cause of the index corruption has been
fixed. (I cleaned up some problems in the btree index code not long
ago, but have no way to tell if this is related.) I don't suppose you
have a way of reproducing the problem from a cold start?
> Also, during the day before the dump/vacuum began to fail, the backend was
> resetting itself every few minutes with the message:
> Server process (pid 25155) exited with status 11 at Fri Aug 11 11:47:47 2000
> Terminating any active server processes...
> I'm not sure what status 11 means.
SEGV crash. There should have been a core dump from that --- is there
a core file in the old database directory, and if so can you get a
backtrace from it?
regards, tom lane
