vacuum fails - Mailing list pgsql-general

From Mirko Kaffka
Subject vacuum fails
Date
Msg-id Pine.GSO.3.96.990614104821.5999A-100000@taifun.interface-business.de
Whole thread Raw
Responses Re: [GENERAL] vacuum fails  (jim@reptiles.org (Jim Mercer))
List pgsql-general
Hi all,

we are using PostgreSQL 6.4.2 under FreeBSD 2.2.8.
At a customers site we start vacuum nightly and for almost two weeks it
has always run successfully. Now it fails and a 'vacuum verbose', run
from psql, shows the following message:

...
NOTICE:  --Relation pg_class--
NOTICE:  Pages 4: Changed 1, Reapped 4, Empty 0, New 0; Tup 135: Vac 115, Crash 10, UnUsed 14, MinLen 110, MaxLen 160;
Re-using:Free/Avail. Space 14648/124; EndEmpty/Avail. Pages 1/1. Elapsed 0/0 sec. 
NOTICE:  Index pg_class_relname_index: Pages 15; Tuples 135: Deleted 115. Elapsed 0/0 sec.
NOTICE:  Index pg_class_oid_index: Pages 7; Tuples 135: Deleted 115. Elapsed 0/0 sec.
NOTICE:  Rel pg_class: Pages: 4 --> 3; Tuple(s) moved: 0. Elapsed 0/0 sec.
NOTICE:  BlowawayRelationBuffers(pg_class, 3): block 3 is dirty (private 0, last 0, global 0)
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally before or while processing the request.
We have lost the connection to the backend, so further processing is impossible.  Terminating.

Any ideas how to fix it?  Sometimes before, a large query caused a backend
to die because it exceeded the memory limit. This left some temporary tables
in a state between nonexistent and created. I mean we can not create the
table because postgresql says it already exists and we can not drop it
because postgresql says it does not exist. Could that be the cause of
our problem ?

Thanks for any help in advance,
Mirko


pgsql-general by date:

Previous
From: Herouth Maoz
Date:
Subject: Re: [GENERAL] PL problem
Next
From: jim@reptiles.org (Jim Mercer)
Date:
Subject: Re: [GENERAL] vacuum fails