Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 2064B2E0030 for ; Sat, 21 Jun 2008 13:37:26 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 39390-05 for ; Sat, 21 Jun 2008 13:37:22 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 3065F2E0040 for ; Sat, 21 Jun 2008 13:37:23 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m5LGbG4d019831; Sat, 21 Jun 2008 12:37:16 -0400 (EDT) To: hjeancha@freesurf.fr cc: pgsql-admin@postgresql.org Subject: Re: vacuumdb not enough stack items In-reply-to: <20080621154752.33867bg7xhmsv04c@webmail-html.freesurf.fr> References: <20080621154752.33867bg7xhmsv04c@webmail-html.freesurf.fr> Comments: In-reply-to hjeancha@freesurf.fr message dated "Sat, 21 Jun 2008 15:47:52 +0200" Date: Sat, 21 Jun 2008 12:37:16 -0400 Message-ID: <19830.1214066236@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/191 X-Sequence-Number: 29529 hjeancha@freesurf.fr writes: > i use postgresql version7.4.7 on i386-pc-linux-gnu, autovacuum is > configured to run on this database. Hmm ... in theory autovacuum should have kept you out of trouble, if it was working properly. Were you keeping an eye on its log output? > Doing a manual vacuumdb on each database raise an error message saying: > vacuumdb: vacuuming of database "ez_info1" failed: ERREUR: not enough > stack items What probably happened was that this error blocked autovacuum from completing an anti-wraparound vacuum :-( [ checks code... ] This appears to indicate a corrupted btree index. I don't believe we've ever heard of this error occurring in the field before, so it might be interesting to inquire into exactly what happened to the index --- but if you just want to get out of trouble I'd suggest * VACUUM VERBOSE as superuser. Watch the output to determine which table it fails on. * REINDEX that table. * VACUUM VERBOSE again. This should solve the problem fairly painlessly as long as the corrupted index isn't on a system catalog. If it is, see the man page for REINDEX about how to recover. I'm not sure if vacuuming will get your data back at this point, but it's certainly worth a try. Somewhere in here you should think about moving to a more modern Postgres release. 8.1 and later wouldn't have let you keep going to the point of wraparound with a critical problem like this. regards, tom lane