Hello, I'm having a problem vacuum a table and I didn't see an answer using
the fts engine.
I have two questions:
1) Is this a big problem, can it be fixed, do I have to dump / restore this
table?
2) I found this problem from my nightly cron driven vacuum -a -z. When it
hits this error the entire vacuumdb process stops immediately thus skipping
any remaining databases. Should it do this? Or should it continue on and
vacuum the other databases?
Here is the error:
cms_beau=# vacuum hits; (It works without the analyze phase of backup.)
VACUUM
cms_beau=# VACUUM verbose analyze hits;
NOTICE: --Relation hits--
NOTICE: Pages 8389: Changed 0, reaped 2, Empty 0, New 0; Tup 834575: Vac 0,
Keep/VTL 4/4, Crash 0, UnUsed 6, MinLen 52, MaxLen 121; Re-using:
Free/Avail. Space 376/64; EndEmpty/Avail. Pages 0/1. CPU 0.34s/0.05u sec.
NOTICE: Index hits_id_key: Pages 1831; Tuples 834575: Deleted 0. CPU
0.11s/0.56u sec.
NOTICE: Rel hits: Pages: 8389 --> 8389; Tuple(s) moved: 0. CPU 0.00s/0.00u
sec.
NOTICE: --Relation pg_toast_6742393--
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; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
NOTICE: Index pg_toast_6742393_idx: Pages 1; Tuples 0. CPU 0.00s/0.00u sec.
NOTICE: Analyzing...
ERROR: MemoryContextAlloc: invalid request size 4294079565
cms_beau=#
Additional information:
sort_mem = 16384
shared_buffers = 8192
cms_beau=# select version(); version
-------------------------------------------------------------PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC
2.96
(1 row)
cms_beau=# \d hits Table "hits" Attribute | Type |
Modifier
-------------+--------------------------+-----------------------------------
------------id | integer | not null default
nextval('hits_id_seq'::text)operator_id | integer |connected | timestamp with time zone | default
'now'page | text |
Index: hits_id_key
cms_beau=# select count(*) from hits;count
--------834539
(1 row)
Please let me know if there is any other information you need.
Thank you much,
Matt O'Connor