Re: Vacuum full - disk space eaten by WAL logfiles

"Thomas Madsen" <tm(at)softcom(dot)dk> writes:
> I raised it to 3,000,000 and tried a "VACUUM FULL" on the table. Out
> popped an error when it reached the toast table index: "Number of tuples
> (xxx) not same at number in heap (XXX), recreate index". The numbers
> (XXX) differed by just 2. It then started recreating the index, but
> stopped short when another error popped up: "insertion of duplicate
> keys"-failure.

VACUUM FULL will not try to "recreate the index", so you misinterpreted
what you were seeing.

> I have subsequently attempted to reindex the tables/indexes, but it
> didn't help a bit. I still got the: "Number of tuples (xxx) not same at
> number in heap (XXX), recreate index"- error.

I have some vague memory that it's difficult to get the system to accept
a REINDEX on a toast table or toast index in older versions. REINDEXing
the base table will *not* fix it, you need to specify the toast object
by name. Does it let you do that?

> The last lines keep coming until no more diskspace is left. I searched
> this forum and got some hints to this problem.
> I raised the "checkpoint" default values in postgres.conf to these
> values, which should have decreased the need for diskspace:

It's checkpoints that are responsible for recycling WAL files.
It sounds to me like checkpoints just aren't happening at all, which
seems odd. Does a checkpoint subprocess appear while this is going on?

It might well be that your best bet is to dump and reload that
particular table. You don't necessarily have to use pg_dump, you
could do something like
CREATE TABLE dup AS SELECT * from badtable;
TRUNCATE badtable;
INSERT INTO badtable SELECT * FROM dup;
DROP TABLE dup;
(7.2 had TRUNCATE didn't it? I forget.)

In any case I would *strongly* recommend an update to 7.2.5, which you
can do in-place without a dump/reload. We do not make bugfix releases
on a whim --- there are some pretty serious bugs fixed between 7.2.1 and
7.2.5.

regards, tom lane