On Thu, Jan 25, 2018 at 10:41 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Thu, Jan 25, 2018 at 12:14 AM, Fabrízio de Royes Mello > <fabriziome...@gmail.com> wrote: >> >> >> 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 >>> > > Hmm, I'd rather think to log the message at LOG level and to have a > new GUC to control the size of maximum of work-items array . I think > we should always notify users that work-item couldn't get added > because it can become a potential performance problem. Also it might > lead other problems once we have other types of work-item. In the log > message, we can hint for user that you might want to increase maximum > of work-items array. > >> >> Looking better for the autovacuum code your patch will work just for BRIN >> request "brin_summarize_range", correct? >> > > Correct. >
I've added this to next CF so as not to forget. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
