RE: Vacuum analyze problem

The last bit of vacuum verbose analyse

NOTICE:  --Relation pg_ipl--
NOTICE:  Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/
0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEm
pty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
NOTICE:  --Relation pg_inheritproc--
NOTICE:  Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/
0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEm
pty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
NOTICE:  --Relation pg_rewrite--
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.
!#

Yes there is a core file in the dir with the database files

bash-2.04$ ls -l core
-rw-------    1 postgres postgres  2600960 Mar  2 10:02 core
bash-2.04$ date
Fri Mar  2 10:02:32 EST 2001
bash-2.04$ gdb core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"..."/var/lib/pgsql/data/base/gsmai
n_test/core": not in executable format: File format not recognized

(gdb) where
No stack.
(gdb)

gdb does not seem to like the core file format though

Regards,

John

-----Original Message-----
From:    Tom Lane
Sent:    Friday, 2 March 2001 11:50 AM
To:    jhatfield@g-s.com.au
Cc:    'PostgreSQL Admin'
Subject:    Re: [ADMIN] Vacuum analyze problem

John Hatfield <jhatfield@g-s.com.au> writes:
> My problem is when running the vacuum with analyze an error occurs but
> it runs ok without the analyse.

Try "vacuum verbose analyze" so you can see which table it's failing on
(or, just look in the postmaster log to see which table is mentioned
last).  There's probably a core file left from the crashed backend;
can you get a stack backtrace from it with gdb?

            regards, tom lane