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 1sA6lK-007bO7-Dg for pgsql-general@arkaria.postgresql.org; Thu, 23 May 2024 11:37:35 +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 1sA6lK-00BODf-FM for pgsql-general@arkaria.postgresql.org; Thu, 23 May 2024 11:37:34 +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 1sA5xe-00Avtb-NJ for pgsql-general@lists.postgresql.org; Thu, 23 May 2024 10:46:14 +0000 Received: from mail-qt1-x833.google.com ([2607:f8b0:4864:20::833]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sA5xb-001be7-0i for pgsql-general@lists.postgresql.org; Thu, 23 May 2024 10:46:13 +0000 Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-43e06d21a06so13336691cf.3 for ; Thu, 23 May 2024 03:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716461170; x=1717065970; darn=lists.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=HGP5SL7/EVxc90OvsY3eh5/yVNqbFCwCp4FZ1tKMoB4=; b=bBd1B4REGL61/FeZDu3G+PJi4+gUUym8aFK6ytYeQpZHeGyulFl5iJOGxWa4tm3Jnv UsJh78hQJGQxe/7BxnW5CrDRMTtslUFKidqw6dBxfsEThmIJn/NRfXp6drH3uzla1+mr e+GyGiW+QW3WNGHRjROrDz5ECxQg2GZs3Z7jT7KGI+NJwtDsrCnAO8I52KMFL/NJDazL Mm8AxL6avYvuR8FL9BaUgf3c9Bo2Wg7f07FDFJz+lHD9VoQRmnUeA+uiGyOC1zMWs/G3 FgcI8/0YS89GGzSmtoaiZYjsB0gKC/29MHZGwgQiR2DtJ+9bIbAR4fettplLaXORlwT9 QR4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716461170; x=1717065970; 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=HGP5SL7/EVxc90OvsY3eh5/yVNqbFCwCp4FZ1tKMoB4=; b=QzgIviJsO0ThLMHQfadyFqtyjdVzFknts8kcQanokKWxYO6gu02rNSt8rKVQHfSM2k 3pvDnjowq7Xb5G/QJIavKyawwaGnUI67lTEqxySsmVcX6PpiFj+GkzmmsjvPYQgNEz7c rCdrkPUbKvfu2QMT8fX9akcYJpjf8WS2m1e6R/77wS5rvpAgmKUnviiiLOhF3rYx1Xkm gkrauJENiLkVFGHt4fIYKg/JPyHCk3C33Xfwb9H9Ron+Qijsu0RDqBh51Wbx049CtUqt rQx5MaJPLiTafHC86XI+XIWYqswH3jUZaI/nqmMW/poXnaBPQAVBSFSL6JrUNyvXy7OE QUew== X-Gm-Message-State: AOJu0YwGQtY+OoyFJVP0q2Sf66a/+Gm1N84hBTVekJam138ncXDzhXOz YVjhS+Y/YjJm0bQ/bDusSp5/mnIHG3F0io/DyAamWmqD936aDRnurxsfYP/2cl8DV1sTxL/7CqS 4FLLZvTtjBfe0cTch9s5plHYuE6M= X-Google-Smtp-Source: AGHT+IGDwISo79r80B1gdNxQ2lojUeke8PfeePu6oa1KwAjG4Owawk4MhOGpj4S5J4puSq2ve8wy6cbT2ICKh6gVH/o= X-Received: by 2002:a05:6214:5c47:b0:6ab:631d:324b with SMTP id 6a1803df08f44-6ab7f34e3b6mr44464776d6.14.1716461169919; Thu, 23 May 2024 03:46:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jethish Jethish Date: Thu, 23 May 2024 16:15:58 +0530 Message-ID: Subject: Re: Backup failure Postgres To: =?UTF-8?Q?Torsten_F=C3=B6rtsch?= Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000004dcfa206191cc219" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004dcfa206191cc219 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, I have tried by increasing the max_standby_streaming_delay but I'm facing lag issues on the replica server. When i increase the max_standby_streaming_delay even if a query runs for 2 minutes I'm facing lag issues for 2 minutes. Please suggest here. Data size is 3TB On Thu, May 23, 2024, 3:53=E2=80=AFPM Torsten F=C3=B6rtsch wrote: > As the error message says, your query was aborted due to it conflicting > with recovery. There are many ways to deal with that. You could enable > hot_standby_feedback on the replica. You could disconnect the replica fro= m > the master for the time the COPY takes (reset primary_conninfo). You coul= d > increase max_standby_streaming_delay. Perhaps you could also wrap the COP= Y > operation in pg_wal_replay_pause() / pg_wal_replay_resume(). > > On Thu, May 23, 2024 at 11:59=E2=80=AFAM Jethish Jethish > wrote: > >> I'm frequently facing the below error while performing backup. Someone >> please tell how solve this issues. >> >> >> Failed : pg_dump: error: Dumping the contents of table "botsession" >> failed: PQgetResult() failed. pg_dump: error: Error message from server: >> ERROR: canceling statement due to conflict with recovery DETAIL: User qu= ery >> might have needed to see row versions that must be removed. pg_dump: err= or: >> The command was: COPY public.botsession (id, userid, data, iscompressed)= TO >> stdout; >> > --0000000000004dcfa206191cc219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten,

= I have tried by increasing the max_standby_streaming_delay but I'm faci= ng lag issues on the replica server.

When i increase the max_standby_streaming_delay even if a quer= y runs for 2 minutes I'm facing lag issues for 2 minutes.

Please suggest here.
Data size is 3TB

On Thu, May 23, 2024, 3:53=E2=80=AFPM Torsten= F=C3=B6rtsch <tfoertsch123@gm= ail.com> wrote:
As the error message says, your query was aborted due to it conflictin= g with recovery. There are many ways to deal with that. You could enable ho= t_standby_feedback on the replica. You could disconnect the replica from th= e master for the time the COPY takes (reset primary_conninfo). You could in= crease max_standby_streaming_delay. Perhaps you could also wrap the COPY op= eration in pg_wal_replay_pause() / pg_wal_replay_resume().

On Thu, May 23, 2= 024 at 11:59=E2=80=AFAM Jethish Jethish <jethish777@gmail.com> = wrote:
I'm frequently facing the below error while performing backup= . Someone please tell how solve this issues.


Failed : pg_dump: error: Dumping the contents of table "= botsession" failed: PQgetResult() failed. pg_dump: error: Error messag= e from server: ERROR: canceling statement due to conflict with recovery DET= AIL: User query might have needed to see row versions that must be removed.= pg_dump: error: The command was: COPY public.botsession (id, userid, data,= iscompressed) TO stdout;

--0000000000004dcfa206191cc219--