Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1up7h0-00H3Wn-R2 for pgsql-general@arkaria.postgresql.org; Thu, 21 Aug 2025 15:59:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1up7h0-00HGNc-0P for pgsql-general@arkaria.postgresql.org; Thu, 21 Aug 2025 15:59:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1up7gz-00HGNU-Lh for pgsql-general@lists.postgresql.org; Thu, 21 Aug 2025 15:59:10 +0000 Received: from fhigh-b5-smtp.messagingengine.com ([202.12.124.156]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1up7gy-0017KI-08 for pgsql-general@lists.postgresql.org; Thu, 21 Aug 2025 15:59:09 +0000 Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfhigh.stl.internal (Postfix) with ESMTP id 58AC27A01E6; Thu, 21 Aug 2025 11:59:05 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Thu, 21 Aug 2025 11:59:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1755791945; x=1755878345; bh=D0mHkX0kMihID4bVEjjLuhqPf7Ey/MsRiHQmaf8mNY8=; b= hYGegAcdds1vg5VrA6puIrE0xyzHfPaxetIBiCzuLsr/lHLAZ5NS0CqNmTwtTf0n K+AKq7k1zTIb1hcC/yIfwmpOe9enzqzr/eD2K3L8HpKP4ydUbzgOH0ZvUkr0PrHE lMrLOGoF5wTQRBYzdlb9/rf+SMni4auMLz0L+hIdo8fbtRNEgNcRoSq1jRoYidyd /+BVZxJgKrcPwuY/Wi4CSmr1H4YLtf9iFybShd+yhMwc2fRKeMO1niYlLn1PCk5T gswchOrrAvX+9LFJIERpuN/xhdtE/BAarKUXrt7zY2A9cNgEspfE+vhHUid8eO+E Y1QstrK708/92AVkXOeK1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1755791945; x= 1755878345; bh=D0mHkX0kMihID4bVEjjLuhqPf7Ey/MsRiHQmaf8mNY8=; b=V XyVRRFawZn46/aWJ40L2trSyzVgyjBFUFYZF3tbEtv2OHXjSKW/8hyr6LTwLm2lb 8E+ArqaywzFyBe4mWcf0o/XWnw/Q69OR8eNDqGi8E/WGtWaQuBtmDw2y7GPotbKT C5R0SNhDN9DquyixmSzCPyM0ozctQNiW93vVeTyLhbRlwr9ig3WKs5CA2+Px8zj6 2HmuBJr5ewfqDuhHf3mgroFMzLh+prDeubp3vFeUH2N4PkpLIbwUkLKsuauxO6le XIon0ZnbiqvW6a6m7n2oEWVqBALZHrZYuInpNN8o4Y7p7qbul06AmES5PaG9Tfek 0D2JN4d9WHM/Pg2/T47NA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduieduieeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeetughrihgr nhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomh eqnecuggftrfgrthhtvghrnhepfeegfeeiuedtgffgteeggfehkeejheetieeliefgteei keejvdeiveeigfehvedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhdpnhgs pghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggvphgvsh iiseguvghpvghsiidrtghomhdprhgtphhtthhopehpghhsqhhlqdhgvghnvghrrghlsehl ihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Aug 2025 11:59:03 -0400 (EDT) Message-ID: Date: Thu, 21 Aug 2025 08:59:03 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Streaming replica hangs periodically for ~ 1 second - how to diagnose/debug To: depesz@depesz.com Cc: PostgreSQL General References: <05969854-0d19-4726-ae1b-586659dd443b@aklaver.com> <25334887-f1c3-40a1-94b0-753c7d67ae2b@aklaver.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 8/21/25 08:13, hubert depesz lubaczewski wrote: > On Thu, Aug 21, 2025 at 08:04:25AM -0700, Adrian Klaver wrote: >> By bouncer I assume you mean something like pgBouncer, a connection pooler. >> Is it possible to determine what bouncer the queries in question are coming >> from? > > From the POV of db, all queries are coming from one of N localhost > bouncers. N is usually 2…6. > From the POV of the local bouncers, the queries come from range of > remote bouncers. > > Generally we haven't seen any correlation between queries coming from > specific ranges of ips. Logged queries, the ones that we see with > runtime of 1s, have comments that indicate source, and they some from > "all-around". Specifically, "DISCARD ALL" queries are generated by > bouncers themselves (both layers). Well so much for that theory:) > > Just so that it will be clear, I don't expect anyone to be able to > diagnose the problem based on description. I'm looking more into idea > what to look for. The issue is that with the situation being pretty > short, and happening on servers with non-trivial query load, I can't do > stuff, like, for example, strace, stuff. Getting to the bottom of the bag of ideas: Have you looked at the OS system log for the time period involved? You mentioned this seemed to involve PREPARE and DISCARD ALL. Is this the same set of statements or is it all over the place? Also it would be helpful to know what bouncer you are actually using and what mode you are running in? > > Best regards, > > depesz > -- Adrian Klaver adrian.klaver@aklaver.com