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.96) (envelope-from ) id 1waW8F-001rIf-0F for pgsql-general@arkaria.postgresql.org; Fri, 19 Jun 2026 10:07:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1waW8D-00Ff8i-0P for pgsql-general@arkaria.postgresql.org; Fri, 19 Jun 2026 10:07:25 +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.96) (envelope-from ) id 1waW8C-00Ff8a-2O for pgsql-general@lists.postgresql.org; Fri, 19 Jun 2026 10:07:24 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1waW8A-00000001Fa1-2yRB for pgsql-general@postgresql.org; Fri, 19 Jun 2026 10:07:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Type:MIME-Version:References:Reply-To: Message-ID:Subject:Cc:To:Sender:From:Date:Content-Transfer-Encoding: Content-ID:Content-Description; bh=wrjVbiAIkIc1HhFD5ISW6cy0/bsGVqo4CTdpRmF3As8=; b=DOc3F+sVFSb6xV6AS7sV9ke/M1 8V309+PS3Vcb3sqER7fT662RodrsCKaiyisz1YaCrxl0JhpDnN0u8SYWkvYvDjvCVS31saVWndIpa N9VkdwthWbaEdABDjvEvvbPYkFSI914/XLLWD7rmshdJDdHVwQMfG/nHjPnPm599P5F8=; Received: from depesz by depesz.com with local (Exim 4.98.2) (envelope-from ) id 1waW89-00000002Jwy-1vz2; Fri, 19 Jun 2026 12:07:21 +0200 Date: Fri, 19 Jun 2026 12:07:21 +0200 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: Laurenz Albe Cc: Thom Brown , pgsql-general mailing list Subject: Re: Why is WAL-file based replica stuck for long time (hour?) in IPC:RecoveryConflictSnapshot ? Message-ID: Reply-To: depesz@depesz.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jun 19, 2026 at 09:06:12AM +0200, Laurenz Albe wrote: > On Thu, 2026-06-18 at 15:33 +0200, hubert depesz lubaczewski wrote: > > On Thu, Jun 18, 2026 at 02:07:36PM +0100, Thom Brown wrote: > > > Have you got anything in the logs that say "conflict with recovery"? > > > Also, I know you are just running count(*), but is there a transaction > > > being left open? > > > SELECT pid, state, xact_start, query > > > FROM pg_stat_activity > > > ORDER BY xact_start NULLS LAST; > > > Any 'idle in transaction' for too long? > > > What is max_standby_streaming_delay and hot_standby_feedback set to? > > > > No transactions were happening then. These are our "Disaster Recovery" > > instances, and they are generally unused. > > > > max_standby_streaming_delay is 10 minutes > > hot_standby_feedback is on. > > > > Please note that these are *NOT* doing streaming replication! > > Could it be bug #19490 [1]? > That would be fixed in the next minor releases. Maybe it's related, but there are two issues: 1. it's not streaming replication 2. waitevent/type doesn't match. in my case it's IPC/RecoveryConflictSnapshot Best regards, depesz