Re: Failed to request an autovacuum work-item in silence - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Failed to request an autovacuum work-item in silence
Date
Msg-id 20180314150641.pxoykg3j7winlsgx@alvherre.pgsql
Whole thread Raw
In response to Re: Failed to request an autovacuum work-item in silence  (Ildar Musin <i.musin@postgrespro.ru>)
Responses Re: Failed to request an autovacuum work-item in silence  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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 by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Faster inserts with mostly-monotonically increasing values
Next
From: Jesper Pedersen
Date:
Subject: EXPLAIN of Parallel Append