Re: Add wait event for log emission?

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/

In response to

Responses

Browse pgsql-hackers by date

  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?