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 1uzhec-006Ixl-Gk for pgsql-novice@arkaria.postgresql.org; Fri, 19 Sep 2025 20:24:26 +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 1uzheb-009MjO-3q for pgsql-novice@arkaria.postgresql.org; Fri, 19 Sep 2025 20:24: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.94.2) (envelope-from ) id 1uzhea-009MjG-RZ for pgsql-novice@lists.postgresql.org; Fri, 19 Sep 2025 20:24:24 +0000 Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uzheW-001lAo-3C for pgsql-novice@postgresql.org; Fri, 19 Sep 2025 20:24:24 +0000 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-75731ec93bcso865990a34.1 for ; Fri, 19 Sep 2025 13:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758313460; x=1758918260; darn=postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IcmieG8ZxgbnmGLVXYr4akKYCuLtpTHxjCsXQRUuEPU=; b=UsaqaLlMl+2x+hIgXn3O5XzLdqKjK8K3otW3UmlKvXVSJMH0FyVYTxZ7/87pfIG6px vAWIwhGjnk3WV1XBLJYkt11GYYnvNkbVsQabX02Q0gh+pp2cXStj1mVUx7XdNxir8s3O W9U6G18AIsu5ec+lXq4Tl4qMl4rhp1f+68mAoUE2WpR/1r8OT2rXgfeVxGDOE9sOLC1Y j5VQu4O+CEf0xIsVObjlkZ2l9KIMpAJTSQRBx0NR2Vl1Bhqm2EdXNOsNNLmvbo/FqgsL V9ypsgRrcdpLkxEmOC6UGvNhQG9RVyGL/aNLI6elz4WRIW7wgFNemBaSL1Np/FzUYq4w 0Sag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758313460; x=1758918260; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IcmieG8ZxgbnmGLVXYr4akKYCuLtpTHxjCsXQRUuEPU=; b=pI1D/JJGAd6GSFyotAvDpYZ+N/yFWJMQkjclhYh+3Xbbpcoi1s7ly8dLV6rARzYxY1 VBzhzS1PetUPWbof6duRh88MXxd4hnWcNlNgLJAEaznR4n8N7umxyPJaVzxGFlVuZl3o mulmYWRsukcUMsOw4WhkP/7V7t/xBSj6wqhOWc5tzK7YVngCd2/MSio+ogqTyjclePyL Ik/cbAdzsYgoOQPJx4gjpJ1DPc5hZ3QPMw0bJSL/OoVyEV2CqiTUxI9jJYurI3klbBMs C7QfYdDBlGaHsvQ5yZ994JxUhDsn2UBlXzG/dyaPC+ESgPXHfc1vZ8d/HCkfwXmfEhIL 6f1g== X-Gm-Message-State: AOJu0YzL+9E7jOKCXFpBpzt3J7+nt2nb1TbS9Yko8kTLceIWTlm47rFV gEwO4Ssc1e8yvmOTk41pfs6VQtTzBHH9V539zaSfXyz5/2FTA1L5eIJL9UwelA5bzVXbn/fkH6t 7kQ7ZTgWMwD4O2DlvnF2kzLruWU2aoAE= X-Gm-Gg: ASbGnctJ8c5p9ZPnLhSpdZbg2iIrYje+xqpcfPJANeAxdFeq7oe9LgoOYo/RICBcZCS 5dSeD73WThqSKT0TCUfWIgbgPVL8tyRwzQ5Qppu6KmRLMEg/LFv0fdqZ0CtFkag4Wag8j/msDTC Mfw+WTX1sJWBhCOqmPz7swV53MNWaV1OJEgK4/Hog5M5oXQTZXPGGRWWaRWuoilmeyNiBLi7EWx U4G+A== X-Google-Smtp-Source: AGHT+IFOfMAloV4NeksKXnwSfwVL1DssPoJrv3OAmKdp0xTRkM4/zDyIls9OGY/8ZOixHcLMIVIy3yBHojJbgKeB9yk= X-Received: by 2002:a05:6830:3812:b0:745:a21c:6a63 with SMTP id 46e09a7af769-76f73b17a8cmr2453329a34.9.1758313460002; Fri, 19 Sep 2025 13:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6802:34ce:10b0:5df:b5f6:b71 with HTTP; Fri, 19 Sep 2025 13:24:18 -0700 (PDT) In-Reply-To: <554670a7-7560-4d18-8ecb-8518fddf2b9d@app.fastmail.com> References: <554670a7-7560-4d18-8ecb-8518fddf2b9d@app.fastmail.com> From: "David G. Johnston" Date: Fri, 19 Sep 2025 13:24:18 -0700 X-Gm-Features: AS18NWDdB39V-8ChD-tVgHarppPWyvEWTEGB-hXnfZgel_x3N4-vSyaKzy0wupE Message-ID: Subject: Re: SET transaction_timeout inside a transaction To: Quentin de Metz Cc: "pgsql-novice@postgresql.org" , "amborodin@acm.org" , "aekorotkov@gmail.com" , "japinli@hotmail.com" , "zhjwpku@gmail.com" Content-Type: multipart/alternative; boundary="0000000000002ff28f063f2d4124" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002ff28f063f2d4124 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, September 19, 2025, Quentin de Metz wrote: > > > It appears that changing the transaction_timeout when inside a transactio= n > does not work as expected. > > Running the following script on master: > > SET transaction_timeout =3D '1s'; > BEGIN; > SET transaction_timeout =3D '3s'; > SELECT pg_sleep(2); It=E2=80=99s seems perfectly reasonable that as soon as a transaction begin= s it sets up a timer using the then-current value of transaction_timeout. And that changing the variable doesn=E2=80=99t affect any already established t= imers. David J. --0000000000002ff28f063f2d4124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, September 19, 2025, Quentin de Metz <quentin@de.me.tz> wrote:

It appears that changing the transaction_timeout when inside a transaction = does not work as expected.

Running the following script on master:

SET transaction_timeout =3D '1s';
BEGIN;
SET transaction_timeout =3D '3s';
SELECT pg_sleep(2);

It=E2=80=99s seems perf= ectly reasonable that as soon as a transaction begins it sets up a timer us= ing the then-current value of transaction_timeout.=C2=A0 And that changing = the variable doesn=E2=80=99t affect any already established timers.

David J.

--0000000000002ff28f063f2d4124--