Re: Add wait event for log emission?
От | Andres Freund |
---|---|
Тема | Re: Add wait event for log emission? |
Дата | |
Msg-id | 20230614001858.rl7e2b7gk4o7g6ej@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Add wait event for log emission? (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Add wait event for log emission?
|
Список | pgsql-hackers |
Hi, On 2023-06-13 20:55:19 +0200, Magnus Hagander wrote: > On Tue, Jun 13, 2023 at 6:59 PM Andres Freund <andres@anarazel.de> wrote: > > > > Hi, > > > > I just helped somebody debug a postgres performance problem that turned out to > > be not actually be postgres' fault. It turned out to be because postgres' > > stdout/stderr were piped to a program, and that program was slow. Whenever the > > pipe buffer filled up, postgres stopped making progress. > > > > That's not postgres' fault. But we make it too hard to debug such an > > issue. There's no way to figure this out from within postgres, one pretty much > > needs to look at stack traces. > > > > I think we should add a few wait events for log emission. I think it'd be good > > to have one wait event for each log destination. > > > > That's not perfect - we'd e.g. still not be able to debug where the logger > > process is stuck, due it not being in pg_stat_activity. But other processes > > reporting the wait event for writing to the logger process would be a pretty > > good hint. > > > +1. > > Would it make sense to at the same time create a separate one for > syslog, or just use the same? I think it should be a separate one for each of the log paths in send_message_to_server_log(). I don't think we gain anything by being stingy here - and it's not like we add one every other day. I do wonder if it'd be worth setting up a wait event around emit_log_hook - it's somewhat of a misuse of wait events, but might be useful nonetheless? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: