To: Susan Russo <russo@morgan.harvard.edu>
cc: harvsys@morgan.harvard.edu, pgsql-performance@postgresql.org
Subject: Re: does VACUUM ANALYZE complete with this error? 
In-reply-to: <200705231818.l4NIIfdA012503@larrys.harvard.edu> 
References: <200705231818.l4NIIfdA012503@larrys.harvard.edu>
Comments: In-reply-to Susan Russo <russo@morgan.harvard.edu>
	message dated "Wed, 23 May 2007 14:18:41 -0400"
Date: Wed, 23 May 2007 14:31:01 -0400
Message-ID: <22911.1179945061@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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: 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