Re: Logging parallel worker draught
От | Robert Haas |
---|---|
Тема | Re: Logging parallel worker draught |
Дата | |
Msg-id | CA+TgmoaSO-9Oh88TarrSCg9=_0HJssCqwsEvMk_2hjfkG0+poA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logging parallel worker draught (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Logging parallel worker draught
|
Список | pgsql-hackers |
On Tue, May 2, 2023 at 6:57 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > We can output this at the LOG level to avoid running the server at > DEBUG1 level. There are a few other cases where we are not able to > spawn the worker or process and those are logged at the LOG level. For > example, "could not fork autovacuum launcher process .." or "too many > background workers". So, not sure, if this should get a separate > treatment. If we fear this can happen frequently enough that it can > spam the LOG then a GUC may be worthwhile. I think we should definitely be afraid of that. I am in favor of a separate GUC. > > What I was wondering was whether we would be better off putting this > > into the statistics collector, vs. doing it via logging. Both > > approaches seem to have pros and cons. > > I think it could be easier for users to process the information if it > is available via some view, so there is a benefit in putting this into > the stats subsystem. Unless we do this instead. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: