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

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: [pgsql-www] pg_autovacuum is nice ... but ...
Дата
Msg-id 418FA179.70408@Yahoo.com
обсуждение исходный текст
Ответ на Re: [pgsql-www] pg_autovacuum is nice ... but ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [pgsql-www] pg_autovacuum is nice ... but ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Remove: * Allow database recovery
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Remove: * Allow database recovery