Susan Russo <russo@morgan.harvard.edu> writes:
>> What PG version is that? I recall we fixed a problem recently that
>> caused the requested max_fsm_pages to increase some more when you'd
>> increased it to what the message said.
> 8.1.4
OK, I checked the CVS history and found this:
2006-09-21 16:31 tgl
*
contrib/pg_freespacemap/README.pg_freespacemap,contrib/pg_freespacemap/pg_freespacemap.c,contrib/pg_freespacemap/pg_freespacemap.sql.in,src/backend/access/gin/ginvacuum.c,src/backend/access/gist/gistvacuum.c,src/backend/access/nbtree/nbtree.c,
src/backend/commands/vacuum.c,src/backend/commands/vacuumlazy.c,src/backend/storage/freespace/freespace.c,src/include/storage/freespace.h:
Fixfree space map to correctlytrack the total amount of FSM space needed even when a singlerelation requires more than
max_fsm_pagespages. Also, make VACUUMemit a warning in this case, since it likely means that VACUUM FULLor other
drasticcorrective measure is needed. Per reports fromJeff Frost and others of unexpected changes in the
claimedmax_fsm_pagesneed.
This is in 8.2, but we didn't back-patch because it made incompatible
changes in the contrib/pg_freespacemap views.
As the commit message says, the behavior of having the requested
max_fsm_pages value move up after you increase the setting is triggered
by having individual tables that need more than max_fsm_pages. So you
definitely have got a problem of needing more vacuuming...
regards, tom lane
