| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Cc: | "Kieran Cooper, Lyris UK" <kieran(at)lyris(dot)co(dot)uk>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Vacuum stops with misleading max_fsm_pages error |
| Date: | 2007-04-16 22:36:26 |
| Message-ID: | 11516.1176762986@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Kieran Cooper, Lyris UK wrote:
>> INFO: free space map contains 20914 pages in 61 relations
>> DETAIL: A total of 14992 page slots are in use (including overhead).
>> 14992 page slots are required to track all free space.
>> Current limits are: 900000 page slots, 6000 relations, using 5659 kB.
> I am not sure what your question is. The above looks perfectly reasonable.
I think he's wondering why the second number is less than the first.
AFAICT that should be impossible after a VACUUM FULL, but there are
probably tables that haven't been touched by the VACUUM FULL --- stuff
in other databases being one obvious possibility. As for the vacuum
not having done every table in the current database, did you run it
as superuser?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kieran Cooper, Lyris UK | 2007-04-17 07:35:41 | Re: Vacuum stops with misleading max_fsm_pages error |
| Previous Message | Matthew T. O'Connor | 2007-04-16 22:14:38 | Re: Vacuum stops with misleading max_fsm_pages error |