max_fsm_pages question

Поиск
Список
Период
Сортировка
От Michael Monnerie
Тема max_fsm_pages question
Дата
Msg-id 201001251219.12530@zmi.at
обсуждение исходный текст
Список pgsql-admin
I got this log on 8.3.9:

Jan 24 02:13:28 db23.zmi.at postgres[29696]: [3-1] DB= U= H= WARNING:
relation "pg_toast.pg_toast_1910021" contains more than "max_fsm_pages"
pages with useful free space
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [3-2] DB= U= H= HINT:
Consider using VACUUM FULL on this relation or increasing the
configuration parameter "max_fsm_pages".
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [4-1] DB= U= H= LOG:
automatic vacuum of table "dbmail.pg_toast.pg_toast_1910021": index
scans: 1
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [4-2]      pages: 0
removed, 740218 remain
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [4-3]      tuples: 601310
removed, 2397087 remain
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [4-4]      system usage:
CPU 5.73s/1.92u sec elapsed 835.67 sec

and I'd like to know
1) which db uses pg_toast.pg_toast_1910021? (Later I found it:) That
should be dbmail, as it writes "dbmail.pg_toast.pg_toast_1910021" later
on. But wouldn't it be good to log that directly? Making it easier for
admins...
2) what table is using that toast?
3) why did postgres suddenly decide to remove the old cruft suddenly?

Autovacuum is on, the nightly backups do an extra "vacuum analyze", and
once a week a CLUSTER is done for the big tables. Maybe I missed one?


--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://it-management.at
Tel: 0660 / 415 65 31

// Wir haben zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://willhaben.at/iad/realestate/object?adId=15923011

Вложения

В списке pgsql-admin по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: LC_COLLATE could cause a LOWER/UPPER/ILIKE malfunction?
Следующее
От: Julius Tuskenis
Дата:
Сообщение: how to speed ilike