Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQdFJ-0007hC-5B for pgsql-admin@arkaria.postgresql.org; Sat, 24 Nov 2018 19:05:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gQdFH-00010v-93 for pgsql-admin@arkaria.postgresql.org; Sat, 24 Nov 2018 19:05:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQdFH-00010o-0q for pgsql-admin@lists.postgresql.org; Sat, 24 Nov 2018 19:05:35 +0000 Received: from mx2a.mailbox.org ([2001:67c:2050:104:0:2:25:2] helo=mx2.mailbox.org) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQdF8-0007q3-Cp for pgsql-admin@postgresql.org; Sat, 24 Nov 2018 19:05:32 +0000 Received: from smtp2.mailbox.org (unknown [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 97322A118F; Sat, 24 Nov 2018 20:05:22 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id xtbbnL6aczeT; Sat, 24 Nov 2018 20:05:19 +0100 (CET) Message-ID: Subject: Re: canceling statement coming in slave instance From: Laurenz Albe To: Rohit Arora , pgsql-admin@postgresql.org Date: Sat, 24 Nov 2018 20:05:18 +0100 In-Reply-To: References: Organization: Cybertec Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Rohit Arora wrote: > I occasionally encounter below error. > > ERROR: canceling statement due to conflict with recovery > DETAIL: User was holding a relation lock for too long > > While investigating online i came to know that this issue can be handled by below configuration parameters > > "max_standby_archive_delay " > "max_standby_streaming_delay" > > I have increased the value of both the parameters as per below. > > Current values: > "max_standby_archive_delay=30s" ----> was increased it to 300s but we did not get any benefit so we rollback it to original value > "max_standby_streaming_delay=300s" > > But still i occasionally encounter the mention issue. You'd have to set max_standby_streaming_delay to -1 to avoid the error completely. But bear in mind that it can delay replication arbitrarily long. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com