Re: [SQL] Can VACUUM, but cannot do VACUUM ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Albert REINER" <areiner(at)tph(dot)tuwien(dot)ac(dot)at>
Cc: PostgreSQL-SQL <pgsql-sql(at)postgreSQL(dot)org>
Subject: Re: [SQL] Can VACUUM, but cannot do VACUUM ANALYZE
Date: 1999-10-23 16:18:33
Message-ID: 1391.940695513@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"Albert REINER" <areiner(at)tph(dot)tuwien(dot)ac(dot)at> writes:
>> albert=> vacuum analyze;
>> NOTICE: AbortTransaction and not in in-progress state
>> pqReadData() -- backend closed the channel unexpectedly.

This unhelpful trace is the result of the interaction of a couple
of different bugs --- first, vacuum is encountering some sort of
error; then error recovery is messing up in the context of vacuum
(leading first to the NOTICE and then to the coredump); and when
libpq observes connection closure, it drops the original error
message (which it has already received!) on the floor in its haste
to tell you about the closed connection.

The error recovery problem is fixed as of 6.5.2, I believe, so it'd
be worth your while to upgrade. The libpq misbehavior is fixed for
7.0, but it's part of some extensive changes that seemed too risky
to back-patch into 6.5.*. In the meantime, the only way to find out
what that original error message was is to consult the postmaster log
file --- you are running the postmaster with stdout/stderr going to
some logfile, I hope. It should show up right before the NOTICE and
then the postmaster's response to the backend coredump.

Once we have vacuum's error message we can maybe offer some useful
counsel.

regards, tom lane

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 1999-10-23 16:42:00 Re: [SQL] sum-function
Previous Message Oliver Elphick 1999-10-23 13:59:26 Re: [SQL] Can VACUUM, but cannot do VACUUM ANALYZE