Postgre 7.0.3, on RedHat Linux 6.2 stock 2.2.16 kernel.  Nothing special I
can think of, this server has been up and in use for the last 128 days with
no problem.  Last night while cron was performing the nightly vacuuming of
all databases on one of our servers, I got this from cron.

Vacuuming cms
FATAL 1:  _bt_restscan: my bits moved right off the end of the world!
	Recreate index history_id_key.
pqReadData() -- backend closed the channel unexpectedly.
	This probably means the backend terminated abnormally
	before or while processing the request.
connection to server was lost

So this morning I did the following:

cms=# drop index history_id_key;
DROP
cms=# create unique index history_id_key on history(id);
CREATE
cms=# vacuum;
NOTICE:  Index locks_operator_id_ndx: pointer to EmptyPage (blk 44 off 2) -
fixing
NOTICE:  Index locks_operator_id_ndx: pointer to EmptyPage (blk 44 off 1) -
fixing
NOTICE:  Index locks_operator_id_ndx: pointer to EmptyPage (blk 44 off 4) -
fixing
NOTICE:  Index locks_operator_id_ndx: pointer to EmptyPage (blk 44 off 3) -
fixing
NOTICE:  Index locks_operator_id_ndx: pointer to EmptyPage (blk 44 off 5) -
fixing
NOTICE:  Index locks_id_key: pointer to EmptyPage (blk 44 off 2) - fixing
NOTICE:  Index locks_id_key: pointer to EmptyPage (blk 44 off 1) - fixing
NOTICE:  Index locks_id_key: pointer to EmptyPage (blk 44 off 4) - fixing
NOTICE:  Index locks_id_key: pointer to EmptyPage (blk 44 off 3) - fixing
NOTICE:  Index locks_id_key: pointer to EmptyPage (blk 44 off 5) - fixing
NOTICE:  Index locks_case_id_ndx: pointer to EmptyPage (blk 44 off 5) -
fixing
NOTICE:  Index locks_case_id_ndx: pointer to EmptyPage (blk 44 off 2) -
fixing
NOTICE:  Index locks_case_id_ndx: pointer to EmptyPage (blk 44 off 1) -
fixing
NOTICE:  Index locks_case_id_ndx: pointer to EmptyPage (blk 44 off 4) -
fixing
NOTICE:  Index locks_case_id_ndx: pointer to EmptyPage (blk 44 off 3) -
fixing
NOTICE:  Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend died
abnormally and possibly corrupted shared memory.
        I have rolled back the current transaction and am going to terminate
your database system connection and exit.
        Please reconnect to the database system and repeat your query.
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

I have since stopped the database server and all my users are dead in the
water at the moment.  I took postgres down to single user mode and I'm doing
a vacuum and was considering doing an iccpclean.  Any other suggestions?
dump & restore? Any Idea what happened?

Thank you,

Matthew O'Connor



Fri, 23 Mar 2001 10:01:47 -0600
Matthew <matt@ctlno.com>
7.0.3 _bt_restscan: my bits moved right off the end of the world!
Matthew <matt@ctlno.com> writes:
> [ a tale of woe ]

It looks like dropping and rebuilding *all* the indexes on your history
table would be a good move (possibly with a vacuum of the table while
the indexes are removed).  You might want to do a COPY out to try to
save the table data before the vacuum, in case there is corruption in
the table as well as the indexes.

Before you do all that, though, how big is the database?  Would you be
able/willing to tar up the whole $PGDATA tree and let some of us analyze
it?

			regards, tom lane

Fri, 23 Mar 2001 11:58:25 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0.3 _bt_restscan: my bits moved right off the end of the world!