Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q97MI-0008Ot-En for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2023 16:59:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q97MF-0005J5-82 for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2023 16:59:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q97MD-0005If-K7 for pgsql-hackers@lists.postgresql.org; Tue, 13 Jun 2023 16:59:02 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q97MA-0020Pv-CJ for pgsql-hackers@postgresql.org; Tue, 13 Jun 2023 16:59:00 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E0D705C0232 for ; Tue, 13 Jun 2023 12:58:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 13 Jun 2023 12:58:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=1686675536; x=1686761936; bh=MjWa27Ft/lkVTbPpuxG/iyHvL NxPERZVV3jUOB6d5Zo=; b=RRWZtKGCYHSgk29FCcOaQciJV/4srJ7Dq3cFDntkH XmakTsMNncwg4Lipbp5LYTp0SPq7prXWYq04JgbjDS+vQl1AUUW9MHjbKuu7ke9+ HXFlIFKLqYV9e6RwQ4zvMa/xVV1lXP5VaZiSmrdF2i1wCZbsXyKi6YzTyIMqecVL NUYh7GBEpcaYcXfiM0qTCVN6SND8cIvzWUJp2aR+sNXdGb8ahNPALfN8og+/E3By D1fbiO2dLwI3Plu8Z1JGsaQkx5VvDM7TGnpqqxhpNGpVxcdDYBu5vikqq7AzW4oN qHwej/sMd/r4Dc0aaubL4qrEBhAH/Z4akQvyyK58ICQ6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1686675536; x=1686761936; bh=MjWa27Ft/lkVTbPpuxG/iyHvLNxPERZVV3j UOB6d5Zo=; b=amMd2rX7mZtC3P9Q0a9URow4Bz3BohF3vnTFUnYIgRsQAJezRSl q/iae8K3jLdE75u/RRyvHbaVhy/pGqRgwwjv3ry8rLNQM/5dSOMxF/lnopVks9Ep SYZOomWgycrIQ6CAIxtjNT2LZmKx761wInzVvtT3rtvfCF7F1N7kXe+veFBSF2Jp sj1QALbuxAZb2F2P9SL1Hx8TYgKdy07F48wgNvsZQ2iMGwLks7E499FQQQJAuVRX +X8mYaz50ZOJleaD1xA5UaR+XCc0BgT4alo20Z8EbA/lfJ0EloUtWDjKh4U2GA1A 7wB0ap/NM2q51SfbFcc4GidBcv9KIzNC72w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedujedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertd dttddvnecuhfhrohhmpeetnhgurhgvshcuhfhrvghunhguuceorghnughrvghssegrnhgr rhgriigvlhdruggvqeenucggtffrrghtthgvrhhnpeeivdeileegueeutdefudfhfeethe fhvedvleejtefguefgtdeltddutedvheekffenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 13 Jun 2023 12:58:56 -0400 (EDT) Date: Tue, 13 Jun 2023 09:58:54 -0700 From: Andres Freund To: pgsql-hackers@postgresql.org Subject: Add wait event for log emission? Message-ID: <20230613165854.lpw46einthia3tjh@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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. Greetings, Andres Freund