Re: [BUGS] Re: cannot vacuum a database !

From: "Steve Wolfe" <steve(at)iboats(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: [BUGS] Re: cannot vacuum a database !
Date: 2000-08-29 16:47:51
Message-ID: 005f01c011d8$e51c0200$50824e40@iboats.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

> here is the vacuum verbose :

> 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.

Well, here's one possibility. If you're still using 6.5.x or before,
then if you run out of disk space (even temporarily), Postgres can hork up
the table exactly as you describe. You can select from it, insert into it,
etc., but can't vacuum it - nor can you describe (\d) it. A pg_dump won't
work on it, either.

The only way that I was able to rescue the data was to write a Perl script
to select all of the data, and format it into a flat file with a bunch of
SQL statements - basically, re-creating pg_dump. There may have been a more
elegant way of doing it (I think pg_dump has an option to select instead of
copy), but I didn't have a lot of time to research it at the time.

: )

Upgrading to 7 is a very good thing, even if for nothing else than it has
more protection if you run out of disk. And even if you have plenty of
disk, it only takes one junior programmer to mess it all up. : )

steve

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message pgsql-bugs 2000-08-29 18:02:06 prepareStatement.executeUpdate(deleteQuery) returns 1 even when no data deleted.
Previous Message pgsql-bugs 2000-08-29 16:35:34 Callable Statements are not supported at this time.

Browse pgsql-general by date

  From Date Subject
Next Message Emile D Snyder 2000-08-29 17:03:48 replacement for LEFT JOIN in mysql->postres changeover?
Previous Message Brook Milligan 2000-08-29 16:28:43 Re: SQL scripts - sequences