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 1sbylQ-002wL2-WD for pgsql-admin@arkaria.postgresql.org; Thu, 08 Aug 2024 08:44:52 +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 1sbykP-00Cec3-J1 for pgsql-admin@arkaria.postgresql.org; Thu, 08 Aug 2024 08:43:49 +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 1sbykP-00Cebv-4j for pgsql-admin@lists.postgresql.org; Thu, 08 Aug 2024 08:43:49 +0000 Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sbykM-003llZ-HT for pgsql-admin@lists.postgresql.org; Thu, 08 Aug 2024 08:43:48 +0000 Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6bb96ef0e8eso4095176d6.2 for ; Thu, 08 Aug 2024 01:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723106624; x=1723711424; 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=fwS5lCqSdSVQpxvlEEBLyPQ/FYLtLzQ7g+qN16IIGEA=; b=El2agJUKGO00AE/iZvYd9yZJ+RchY5sraJpLJFCR3M5uyURywY9s0YN4K35+B+lf/Z d7WRJz7IAPD50TfCfJaObHFQu8mgKBSuWx+ExSsTLzK1sy6lXSnOocCZuzwCL+iBTPxn VzGlQYUi0Xb+H00H4jH5BNzOQEEevo+MYAa3QxwDOwYZJDo6i/OBhbhcl+bI6nGDWM3J Jjyw88M8GETmGyaaIeZVW9xLD6j52ffij2FQ9mkonpSyD1MrFgwz/EFtiAsCyUA+15cg ZhV4by1bHi2C8SH4layG+36tqGWgc9luu37Kl8zesTTq30Qavb4BmOOpVYQeODxbFVyP NI0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723106624; x=1723711424; 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=fwS5lCqSdSVQpxvlEEBLyPQ/FYLtLzQ7g+qN16IIGEA=; b=trTIKfvKZMIR9RZk8xwUIcqeaFaD7WCdKjar67dcy7IxMeNMu+r3GodpwL4Tto1Dv8 abZiVRuX+uIh169QIoG3giwHkgt/sWqlhLEhJbeAh7qYI3AFuSf4B1dH7CrixuiA6Iq5 kbKs27VfmGpnoNSUFu/+dYjd4UdIdwmZe6y5NT1sM7h+60A/IruVa4e+ZeNuO6utHfG0 uHcYPIeyAr5j0/LUZTuYJkhAr6e2lKl7vGbAIPlEDPcu87k5lJ+WBP9BSM+5IHYBfdBh SX7DcgdEUV+z8S02j1onB+dhbA4TqeVSziRDyHuoQe4Ti0xvhUtmRDdxzFNOzRQa5y2Z K5sQ== X-Forwarded-Encrypted: i=1; AJvYcCUeG/x83QHJK8gbTMNXAOoEZkX/3ETDuLMVbkAPyhHSVYhUR5IDZyqpD5CbQgtp+HLM9i+D2VqglqydZZg3MDkiVTvz58RjrP1bhc3SY0B6sw== X-Gm-Message-State: AOJu0YxDA7INJ5nLEINx+3p1j0Bkoz6bESKS/gPSuVod50OqXS/bdLye +cjhsOv5mL1GXGLH9sScJwe2+xdfq6rZvHmFwdjpHzYbPPo0VJGf44UHA8Dge1IcrLQpexwSmKC i0uU/bPIP3CAJP7S1FjT34Su1ywM= X-Google-Smtp-Source: AGHT+IHVfI6d5X+GB3MuDRlHE0RAUxDOAq12BsUSOSP+wDui7mlei0AO4o3EC8/NyGTmrtA8nhWyFGleboAy8ZssKnw= X-Received: by 2002:a05:6214:2b89:b0:6b0:7ba0:ef67 with SMTP id 6a1803df08f44-6bd6bd333dbmr11540846d6.31.1723106624383; Thu, 08 Aug 2024 01:43:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Imtiaz Date: Thu, 8 Aug 2024 13:43:34 +0500 Message-ID: Subject: Re: Statement_timeout effect on replication user To: "David G. Johnston" Cc: Teja Jakkidi , pgsql-admin Content-Type: multipart/alternative; boundary="00000000000041b51b061f280628" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000041b51b061f280628 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Setting statement_timeout to 1 hour means that any query running longer than 1 hour will be automatically stopped. This applies to queries from applications or users, including those with replication privileges. However, this timeout does not affect the replication process itself. The continuous transfer of WAL files from the primary server to replicas will continue as usual, unaffected by the statement_timeout setting. Regards, Muhammad Imtiaz On Thu, Aug 8, 2024 at 1:56=E2=80=AFAM David G. Johnston wrote: > On Wednesday, August 7, 2024, Teja Jakkidi > wrote: > >> >> I am trying to set statement_timeout parameter to 1 hour at instance >> level due to some production issues that we have noticed with long runni= ng >> queries. >> We also have hot stand by replication setup using a user with replicatio= n >> privilege. Now, if I setup statement_timeout at instance level, will thi= s >> affect the replication session as well? >> > > Set it to 10 seconds and see if anything breaks? > > I would doubt it since replication doesn=E2=80=99t involve SQL statements= . > > David J. > > --00000000000041b51b061f280628 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Setting statement_timeout to 1 hour means that = any query running longer than 1 hour will be automatically stopped. This ap= plies to queries from applications or users, including those with replicati= on privileges. However, this timeout does not affect the replication proces= s itself. The continuous transfer of WAL files from the primary server to r= eplicas will continue as usual, unaffected by the statement_timeout setting= .

Regards,
Muhammad Imtiaz

On Thu, Aug 8, 2024 at 1:56=E2=80=AFAM = David G. Johnston <david.g= .johnston@gmail.com> wrote:
On Wednesday, August 7, 2024, Teja Jakkidi <teja.jakkidi05@gmail= .com> wrote:
I am trying to set statement_timeout parameter to 1 hour at instance level = due to some production issues that we have noticed with long running querie= s.
We also have hot stand by replication setup using a user with replication p= rivilege. Now, if I setup statement_timeout at instance level, will this af= fect the replication session as well?

Set it to 10 seconds and see if anything b= reaks?

I would doubt it since replication doesn=E2= =80=99t involve SQL statements.

David J.

--00000000000041b51b061f280628--