Re: Failed to request an autovacuum work-item in silence

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Failed to request an autovacuum work-item in silence
Дата
Msg-id 20180314150641.pxoykg3j7winlsgx@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Failed to request an autovacuum work-item in silence  (Ildar Musin <i.musin@postgrespro.ru>)
Ответы Re: Failed to request an autovacuum work-item in silence  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
Hello,

Ildar Musin wrote:

> autovac_get_workitem_name() declaration seems redundant and should be
> removed. The same thing with including "utils/lsyscache.h" in brin.c.
> 
> The 'requested' variable in brininsert() I would again rename to something
> like 'success' because a work item is requested anyway but what matters is
> whether the request was satisfied/successful.

Thanks, I pushed this.  I agree with your comments; so I changed
'requested' to 'recorded' and removed those lines.  I also reworded the
log message:

                    ereport(LOG,
                            (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
                             errmsg("request for BRIN range summarization for index \"%s\" page %u was not recorded",
                                    RelationGetRelationName(idxRel),
                                    lastPageRange)));

And added a paragraph to the docs explaining this situation.

Now I'm wondering what will we tell users to do if they get this message
too frequently.  Neither of the obvious options (1. changing the index's
pages_per_range to a larger value;  2. making autovacuum more frequent
somehow) seem terribly useful.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Faster inserts with mostly-monotonically increasing values
Следующее
От: Jesper Pedersen
Дата:
Сообщение: EXPLAIN of Parallel Append