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 1v3ZbP-000atI-BS for pgsql-admin@arkaria.postgresql.org; Tue, 30 Sep 2025 12:37:07 +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 1v3ZbN-009aTF-CG for pgsql-admin@arkaria.postgresql.org; Tue, 30 Sep 2025 12:37:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3ZbM-009aT5-Rc for pgsql-admin@lists.postgresql.org; Tue, 30 Sep 2025 12:37:05 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v3ZbJ-000hLz-31 for pgsql-admin@postgresql.org; Tue, 30 Sep 2025 12:37:04 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-57bd7f0e5baso5663009e87.3 for ; Tue, 30 Sep 2025 05:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759235821; x=1759840621; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uDdGcHz0UlMUnjwdO3Jmc6YkcjP8MV16YTZTA/c3ZP0=; b=SaVQnV52Ha58BlZGr6bISX/OCISqSp+iklfX67/bx1uefrn0Rh1Dqq+jmGTzN7njZq eK3tPrlFONgLItS4V25C7CfcRjSlR4NQUfPBKFa1SeVHd5r+W4PbNp5Wy7P3OBTr5con Bzyyl2bb7QMqgJxt/lB+7VfHFD9ypciMCvQHbkKlr2K37WtVYJUbb04+JLKb3cQs91xF xyCusGLvvUJuHxzVmIIw3kH+XQ05Ti0kBCIFQLEWR7zFZqFE9RXV6WcfXC6P7NFAvFfL DrbobLs8zp+CCTKAijxTYU1INEI65Mw217UjG6rRMa7lU8CfRZ08oyW76qFycUMmTxhM 5tCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759235821; x=1759840621; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uDdGcHz0UlMUnjwdO3Jmc6YkcjP8MV16YTZTA/c3ZP0=; b=lEf7B4Wn9zNbMX1tw4agXwz73V7joA+xTlwx01g6iwMMQEXQQRflW4qu1tK/Rz8i3s WoVXdZQH7uzpC7G/52ygNXAVmGxEICcFUOYzHtMPzfwoul03Hk9FXg/njd5DnjxfI7mC tN++qF/jIpiD30sVwTZMENn3rJh6d4t3NyJ2OpumF71QYj5YOa5BqgMPHrQUzbzPuFv0 iKiUcNSkWhLVTYd/az/EtH0m7X/CtZokeDo1FiEEPobSEs2tXAD+TDKKuSUXjIOAqIji R8clReJVKOZPyO8KpfVli8CMjOjc52Dn2FVNUSCEkBQe8w7flJDFb0SNW2ocYiPtlcSe uMhQ== X-Gm-Message-State: AOJu0YwBVRxR3MN8hiG9CEQ+CVyUjbramOfLTHuBsa5l26Mn71RrKZos M+9JJFK865OoqVPDlJmxdNDUv3lOEh8cXPNwTHUl10Kg/zHzhXXuEjp7jAhKFdZxEHvYDztY+kJ KN6I2Lan+bf0Jw2k0QSOdh7drxocyACc= X-Gm-Gg: ASbGncvWWWMq5RNlt6erC86V8SvuMGDGWs7Xvrf4XpIs/QFRqOELzfTQAkw/SF+/Zjx OI7xvo8qqz9zHLZSiN9e4KS1X3k7ttAuLaDJKl/VO2Xr3qzxP7935wlEoxWN5UxpPwnEw+B/HhX FNozxk1i2yEa6KgorXlOq658o9xeX0mUhYLfTzswhQTd5NTXl5pqswUpc9GKvdONXJF6Sk/R2y1 J+i+RPeNFNnaR5ibwa1it4fMhXeu/tiGRbKyzafI7tPK2hEnPYBOfps5RB8IfGiiu69V3sWg4x4 X-Google-Smtp-Source: AGHT+IGL/E/lindX7BZzWAOR1tVisEqjwicmH9+7GLJMVLxbel/eYQsl9r8AJxRtP1pePUaV4wNjCN5QJxoGikGsD/E= X-Received: by 2002:a05:6512:39d1:b0:578:113c:accb with SMTP id 2adb3069b0e04-582d35df8a6mr6673210e87.46.1759235820742; Tue, 30 Sep 2025 05:37:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Imran Khan Date: Tue, 30 Sep 2025 15:36:48 +0300 X-Gm-Features: AS18NWB9sBahu3StILyOENuw3fCSdMrgZct4hetT8Sy6brq0tAjqEqferFqHTXo Message-ID: Subject: Re: canceling/terminating statement due to conflict with recovery in Replica/DR instances To: Ishan joshi Cc: pgsql-admin Content-Type: multipart/alternative; boundary="0000000000002beb4e06400402ca" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002beb4e06400402ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Isha, I believe you have partitions and correct type of indexes created for those tables. Also, is this 25 TB size grown over many years or just few years old? Parameters tuning can help but won't be a permanent solution. Having multiple replicas I believe can make sense at this point. Thanks, Imran On Tue, Sep 30, 2025, 8:59=E2=80=AFAM Ishan joshi wro= te: > Hi Team, > > We are using Postgresql 16.9 in production and with large database about > 25TB of size. We have patroni setup with replica instance and DR patroni > setup with patroni streaming. > > We have high volume and frequent commit in the database. There are few > large tables for which we asked client to execute queries on DR/Replica > instances but these queries are start getting failed with "canceling > statement due to conflict with recovery" and "terminating statement due t= o > conflict with recovery" error. > > As I understand the behavior is correct but we need to get rid of this > issue. > > I gone through the old posts and some documentation and got to know that > below parameters can help to reduce this error. > > max_standby_streaming_delay > max_standby_archive_delay > hot_standby_feedback =3D off > > Our queries are running for long period that makes me to set this value t= o > some minutes/hours (lets set 900s) which is not feasible for production a= s > it will start impacting the replication lag. Also, the queries will fail = if > it reaches to mentioned thresholds. > > If I set these parameters to "-1" (disable) then there will be direct > impact on replication lag which will impact further queries on replica no= de > and DR cluster. > > Can you please guide If any other better solution present for such > scenario? > > Thanks & Regards, > Ishan Joshi > --0000000000002beb4e06400402ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Isha,=C2=A0

=C2=A0I believe you have partitions and correct type of indexes created = for those tables. Also, is this 25 TB size grown over many years or just fe= w years old? Parameters tuning can help but won't be a permanent=C2=A0s= olution. Having multiple replicas I believe can make sense at this=C2=A0poi= nt.

Thanks,=C2=A0
<= div dir=3D"auto">Imran

On Tue, Sep 30, 2025, 8:5= 9=E2=80=AFAM Ishan joshi <ishanjo= shi@live.com> wrote:
Hi Team,

We are using Postgresql 16.9 in production and with large database about 25= TB of size. We have patroni setup with replica instance and DR patroni setu= p with patroni streaming.

We have high volume and frequent commit in the database. There are few larg= e tables for which we asked client to execute queries on DR/Replica instanc= es but these queries are start getting failed with "canceling statemen= t due to conflict with recovery" and "terminating statement due to conflict with recovery" error.

As I understand the behavior is correct but we need to get rid of this issu= e.

I gone through the old posts and some documentation and got to know that be= low parameters can help to reduce this error.=C2=A0

max_standby_streaming_delay=C2=A0
max_standby_archive_delay=C2=A0
hot_standby_feedback =3D off

Our queries are running for long period that makes me to set this value to = some minutes/hours (lets set 900s) which is not feasible for production as = it will start impacting the replication lag. Also, the queries will fail if= it reaches to mentioned thresholds.

If I set these parameters to "-1" (disable) then there will be di= rect impact on replication lag which will impact further queries on replica= node and DR cluster.

Can you please guide If any other better solution present for such scenario= ?

Thanks & Regards,
Ishan Joshi
--0000000000002beb4e06400402ca--