Re: [pgsql-www] pg_autovacuum is nice ... but ... - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: [pgsql-www] pg_autovacuum is nice ... but ...
Date
Msg-id 418FA179.70408@Yahoo.com
Whole thread Raw
In response to Re: [pgsql-www] pg_autovacuum is nice ... but ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [pgsql-www] pg_autovacuum is nice ... but ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/4/2004 5:44 PM, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@postgresql.org> writes:
>> Moved to -hackers where this belongs :)
> 
>> On Fri, 5 Nov 2004, Justin Clift wrote:
>>> Would making max_fsm_relations and max_fsm_pages dynamically update 
>>> themselves whilst PostgreSQL runs be useful?
> 
> Possibly, but it isn't happening in the foreseeable future, for the same
> reason that we don't auto-update shared_buffers and the other shared
> memory sizing parameters: we can't resize shared memory on the fly.
> 
>> I'm not sure if I like this one too much ... but it would be nice if 
>> something like this triggered a warning in the logs, maybe a feature of 
>> pg_autovacuum itself?
> 
> autovacuum would probably be a reasonable place to put it.  We don't
> currently have any good way for autovacuum to get at the information,
> but I suppose that an integrated autovacuum daemon could do so.

Don't know why this must be an "integrated" autovacuum. Can't the info 
about the FSM usage be presented as system views?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Remove: * Allow database recovery
Next
From: "Marc G. Fournier"
Date:
Subject: Re: [COMMITTERS] pgsql: Remove: * Allow database recovery