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

On Wed, Jan 24, 2018 at 12:31 PM, Fabrízio de Royes Mello <
fabriziomello(at)gmail(dot)com> wrote:
>
>
>
> On Tue, Jan 23, 2018 at 11:44 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:
> >
> > On Tue, Jan 23, 2018 at 8:03 PM, Fabrízio de Royes Mello
> > <fabriziomello(at)gmail(dot)com> wrote:
> > >
> > > Em ter, 23 de jan de 2018 às 03:36, Masahiko Sawada <
sawada(dot)mshk(at)gmail(dot)com>
> > > escreveu:
> > >>
> > >> Hi all,
> > >>
> > >> While reading the code, I realized that the requesting an autovacuum
> > >> work-item could fail in silence if work-item array is full. So the
> > >> users cannot realize that work-item is never performed.
> > >> AutoVacuumRequestWork() seems to behave so from the initial
> > >> implementation but is there any reason of such behavior? It seems to
> > >> me that it can be a problem even now that there is only one kind of
> > >> work-item. Attached patch for fixing it.
> > >
> > >
> > > Seems reasonable but maybe you can use the word "worker" instead of
"work
> > > item" for report message.
> > >
> >
> > Thank you for the comment.
> > Or can we use the word "work-item" since the commit log and source
> > code use this word?
> >
>
> You're correct, I misunderstood it thinking about autovacuum workers and
not the internal workitem array.
>
> As NUM_WORKITEMS is fixed in 256 we don't have any real feedback if in a
real workload this can send a lot of messages to log, so:
> 1) maybe invent a new GUC to control if we need or not to send this info
to log
> 2) change elevel for DEBUG1
>

Looking better for the autovacuum code your patch will work just for BRIN
request "brin_summarize_range", correct?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello