Susan Russo <[EMAIL PROTECTED]> 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: Fix free space map to correctly
track the total amount of FSM space needed even when a single
relation requires more than max_fsm_pages pages. Also, make VACUUM
emit a warning in this case, since it likely means that VACUUM FULL
or other drastic corrective measure is needed. Per reports from
Jeff Frost and others of unexpected changes in the claimed
max_fsm_pages need.
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
