On Wed, Jan 24, 2018 at 12:31 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > > On Tue, Jan 23, 2018 at 11:44 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Tue, Jan 23, 2018 at 8:03 PM, Fabrízio de Royes Mello > > <fabriziome...@gmail.com> wrote: > > > > > > Em ter, 23 de jan de 2018 às 03:36, Masahiko Sawada < sawada.m...@gmail.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
