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 1u9BQe-00GW17-E8 for pgsql-general@arkaria.postgresql.org; Sun, 27 Apr 2025 23:28:56 +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 1u9BQc-00B1Iu-Jw for pgsql-general@arkaria.postgresql.org; Sun, 27 Apr 2025 23:28:55 +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 1u9BQc-00B1Im-5M for pgsql-general@lists.postgresql.org; Sun, 27 Apr 2025 23:28:55 +0000 Received: from mail-il1-x142.google.com ([2607:f8b0:4864:20::142]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u9BQa-002Hbd-2X for pgsql-general@lists.postgresql.org; Sun, 27 Apr 2025 23:28:54 +0000 Received: by mail-il1-x142.google.com with SMTP id e9e14a558f8ab-3d940c7ea71so10299305ab.0 for ; Sun, 27 Apr 2025 16:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745796532; x=1746401332; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=iP8toP1v6+mpVXMEp9DG1e3jt/1OMGNrZfE5KrKvTjg=; b=RYAUsAFsm/ZMtLWXGS6SjHXCFshK9Y0/BdJwo/TdAKTWUjpEwhoCrs/Ed5xTzKImpk UFwV/Bv9CJw+qwvQ1GLph5d25An5bjFmVwd80FyHl4X3+JKO5jyg0FrPkf8Elo0YX1Al ZskHhGtIdHJnWAgvOrWT+lHHFaSUueXsRnyQ921Ny9QtpOESeTRGMjhxG9pBiHl4kkqF YevqzQLj9aeEliKY2VE0PDO5MrfGf4rH6ck/OvDqP0yIjeOuk8hQY0GbBd/Bux9F25UM uEpN3XiAdc/51DipX4h9vL9beih0W+GjBTgzVROxFhqppkHvyPzPc7kGU3sux4jSqKP1 y0ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745796532; x=1746401332; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=iP8toP1v6+mpVXMEp9DG1e3jt/1OMGNrZfE5KrKvTjg=; b=GUeSsClilg2peXwLOaQApLrttC5Q604L3jB2Iw4uOdU8ldyV5KmK/nNsDs8mPHp5Na 6p5325k2QxormNXWKJ6x3R2ulzEgqoflQJlQQtzhWgQm/HMCekyAByDh7Qua0CK0h49f hnYk9hjkux0CyUiHDKXDaeluXPcQmwRMZAG8Jl5MG2coq7/HwX8yhJAz8FyrGJe5pTQU pucnfJ/WZbXfs6PZvRCIubi+PEwA+/fzsifrb831B47rnC5Xyu7JrBcjwPKXWQtsCUmH g2OAWiLmDkBW739kYUdRxbaBY7+E/fX5HYZca5X5aa8rSXm0saPaQvo7SsCfufOVMOjg t3vw== X-Gm-Message-State: AOJu0YySV4pDYR4VKJQsG0K7Ak3uq6zDrWl1ScsDyLl/VprIHYV6vVpB XPovmsM1ZbcByF6XhI0gNngY63fWFzgivvcxzbirlOjBzoC4nFqaPi2hxEb5QmL8mPHU+SPbFyE 4AKm2jBEAxkyhtmS8u+QNLPNHZil1j/MulIE= X-Gm-Gg: ASbGncu65TJUAZWgI24aZ1QcH1im98xJqDaNQ4SEnlqpPKy0blvhR23JU7A4hVpTCSd lAdyfK5wauSZ3Iqv3Ss75YNSuDNORRzGScuSqGr+xq+Ho+H55T1pb8x5oUSZdD/eYU4RsS6HEfq qwMBJfEcKRY2CKYwdGLX+CaXQ= X-Google-Smtp-Source: AGHT+IGpBeoGjrv9TxtLQF/Ft9U65uZ4SqcChSi/gAC0ZpCWp6Rpo8S1iRufydehoaww+JSLoDD5V7QA87iIhqH/CJQ= X-Received: by 2002:a05:6e02:3784:b0:3d8:7a02:a67b with SMTP id e9e14a558f8ab-3d942d629acmr68351635ab.8.1745796532210; Sun, 27 Apr 2025 16:28:52 -0700 (PDT) MIME-Version: 1.0 From: Marcelo Fernandes Date: Mon, 28 Apr 2025 11:28:41 +1200 X-Gm-Features: ATxdqUHNRtegTZV5buQuA_wIU1BlStoQgkQcEEj7Huf2WZd0_sNoBmXUW8MFOUs Message-ID: Subject: Resetting the lock_timeout value for a transaction To: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi folks, I have been using: -- Setting the SESSION lock timeout to 10 seconds SET lock_timeout = '10s'; -- Setting the TRANSACTION lock timeout to 20 seconds BEGIN; SET LOCAL lock_timeout = '20s'; COMMIT; However, I have been caught by the behaviour of "RESET lock_timeout;" when inside and outside a transaction. -- Resets the lock_timeout value for the SESSION. RESET lock_timeout; -- WARNING: This will reset BOTH the SESSION and TRANSACTION lock_timeouts. BEGIN; SET LOCAL lock_timeout = '20s'; RESET lock_timeout; COMMIT; I would have expected that the "RESET lock_timeout;" inside a transaction would only reset the value of lock_timeout for that specific transaction. Or else, there would be an equivalent "RESET LOCAL lock_timeout;" to be used for that. But I can't find anything that does just that. Am I missing something? Example script for convenience: -- This is the default lock_timeout (0s) SHOW lock_timeout; -- Set the SESSION lock timeout (42s) SET lock_timeout = '42s'; SHOW lock_timeout; BEGIN; -- WARNING: This will set a new value for the SESSION lock_timeout from within -- the transaction because it is missing the LOCAL key word! SET lock_timeout = '10s'; SHOW lock_timeout; -- Set it again but this time only for the transaction. This value will not -- affect the session lock_timeout. SET LOCAL lock_timeout = '9s'; SHOW lock_timeout; -- Reset BOTH the SESSION and Transaction lock_timeout (both go back to 0, the -- default). RESET lock_timeout; SHOW lock_timeout; COMMIT; -- Should now be 0s because it was reset inside the transaction. SHOW lock_timeout; Thanks, Marcelo