From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add wait event for log emission? |
Date: | 2023-06-13 18:55:19 |
Message-ID: | CABUevEwkHb_kJGqvFXrz4rTBnVfpr8+ABh-=Y0R3QTPAb2J7tA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 13, 2023 at 6:59 PM Andres Freund <andres(at)anarazel(dot)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?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-06-13 19:32:54 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |
Previous Message | Joel Jacobson | 2023-06-13 18:50:50 | Re: Do we want a hashset type? |