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.96) (envelope-from ) id 1w8HGN-000NNU-0w for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 12:35:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8HGL-005mYd-36 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 12:35:06 +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.96) (envelope-from ) id 1w8HGL-005mYU-1l for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 12:35:05 +0000 Received: from mail-oo1-xc2c.google.com ([2607:f8b0:4864:20::c2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w8HGJ-00000000BJT-3OOn for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 12:35:04 +0000 Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-67bac077116so317053eaf.1 for ; Thu, 02 Apr 2026 05:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775133303; cv=none; d=google.com; s=arc-20240605; b=GBIWuKXNshV2wYxDuc+1nb3VTYcUkR7PU02ILUe1YI1p1Ld9IUdfF2ceILn4WgBtQ8 Ztegi9DEXb7r87DKq9oRL80Ro6gZPkeOv1XUudGSKi8rSWUPGDQssMkXS5Jd5uzkIw2L uz0d3RO1s6/AkqjRR3Q8JDzqrnk+sZj8u9HQOlYE3KacxYNBslVDQxAC5VEVbvo159Fk 52NpaZBNWHZAwmz35G6l6z7ZatAuWgXOArImZrxClDs5to1NNppQVMI9XrP5YKR5uKsP RaBA3G3ARkZweuLtzwyPtqWCScO9oKksBMfDGLcEeWaieqm0TlZL7Ayde6ugMn6+ETuA 9Q4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=guVRYT7sA3VKiCQfnQvA8KiKnJTQQ6/i9+LlLpxOGtA=; fh=uUcSxV4XYC+1ETF3ktAmTotNKpnMc3P8kiLwwxso+Fw=; b=axAqdU642M7VVuU1yDKcQdT12kb+CIxjXe1U5HCnFD56KpnBbdYmXX63Cwc6yjFopc /NLMiPaGezpWoZPaaI4yxLFaes4RBQwoHvFk37Y9FSiz7+Y2CvptLBgS8945z3K1R7p6 ObwAsdOJtT1cBRczdeE+pZoyCSjRrF5kfzezMKG2uJOnaxbfarUatTzlv1LkISxzywRY f5UoJdfCC7RbDQpoVVAZ1Ax/O3Fcy6Bigj6OILEkKH6QUhTqZ3JvNz2asgtf5HnAhRbX 0VmpE5CUXTsbpcEIc6HS/othTMM+fXe6haOFUrll1qVmepHLBuovM7vW7bzW4Zc3ZxBZ nk7w==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775133303; x=1775738103; 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=guVRYT7sA3VKiCQfnQvA8KiKnJTQQ6/i9+LlLpxOGtA=; b=V0By7zjuOgAxf2+YMmie4Meo/nmR2pSZGbCdmOW0SzakCvH6JWvc5zGZugsguJysld EGKnpvL94neFxaDqJXsBQ9cxBwuFvIZ7KQ/5dW6Nd6gpeln8WioGv6dEhgpgodww9AoB 3oyLhGzaTcPsdYlh4bTnMia07WE6hEA3IsN1EKGblQTBuUf0HWjl5kfoRei9YfX06mDJ pzRbdTkfXowmIsHdkU2NiMicdJtKUf+pl9UoKCTqBAOxvSVrVyse87L/TYb7HrOOMXPt /CNLAElu1mc3WL79yQaKFLmvaqr/K5UqQ63p6i+uAtx4gCCzvCDhDddEh9NO4lLaob3o vLcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775133303; x=1775738103; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=guVRYT7sA3VKiCQfnQvA8KiKnJTQQ6/i9+LlLpxOGtA=; b=PtJwg8q5hjyH91aC2cHTQ3zE3b5kkdelLnr+6R8UE3Wv5041vDrcHDBh+9DvoY0rw4 Xs4FEU0yPZqX1zFdE2h8Gky5ACxTT1jdho2DpbcUAFuQeJNPxZrEHeHGGlqhLSa2iAOA TIMANIkeJE4R+ii0+ITFlldOZ0kefdtSZC5TIVDMVMRkjcNVbxA5YevearccXc2bm3l0 yFhC05risF58PzCo8t1gBJ6zr9M6mTgxUetCgs5fosvawqz+XGViDKHXlLX84tbYiTHq QUms87cybj0YSu9EUGo/LIo+Q3d0TxdrKbUw7jiExLohTKD7Qn7SibK3Csyp5un+xeVN /t3w== X-Forwarded-Encrypted: i=1; AJvYcCVftI8s4E81ixKyrtC7EwjR6zMHyCl3XeqEeSkT6S6lOTcYoS7rtfegjA811R+7ZNCPEHmIJxZTbrfaZHv3@lists.postgresql.org X-Gm-Message-State: AOJu0YxLq/TWuq5I6QeLpVIKWbvTVizTjk+HOrFsFgFEjpphUnSwSYTo AO0vAFgmwyYgJql2cLx/awN6rAphuCP/NYFFB3Zt0+wv+ffd4TtTnUlIeMSDf7Hqd3BHzR74Rlq q8XKCvxysa2jtgVMFT1bGZ6LgN4dluQQ= X-Gm-Gg: ATEYQzxQ6u4dNsIQT9OFrsdJvoPd5oDLfovHX7cIDa1jgDHSE/DFr2M4ssiQNVr+bHw 6OzupvUDVJF6vVirQPz2+gMLQbBp7rQ+R3HSFA3qCUNEfqOdJWZ7SlcZcNDp74w68WL+PhyAGt8 F+uGHroRdt9Y0GRY7eFw/m9KQLgy3Nxk4g9Jvl7SYQJ7li4Mx4V/DmJBeuSvr8I+EnhOcRc7m+C Jv/+79DmbN80/tac55FmwcKxJVCpHF6ykC2lT6I5X0vS4f9XmGX1c1ii71nP6mtM85lSjZfeTpU gKShnt/pSOgnscmyBLasXQfaRw9vkSOa7cAKX+d7FA== X-Received: by 2002:a05:6820:1f08:b0:67e:42ca:bf0 with SMTP id 006d021491bc7-67fabcc9dd8mr3639715eaf.39.1775133303334; Thu, 02 Apr 2026 05:35:03 -0700 (PDT) MIME-Version: 1.0 References: <2DCDBFFC-4B03-4EBC-88A3-06AD29933F17@yandex-team.ru> In-Reply-To: From: Greg Sabino Mullane Date: Thu, 2 Apr 2026 08:34:23 -0400 X-Gm-Features: AQROBzBmAUpOt_vK3r7ozp9bzCo4KL40J2mbho1aWTvsD6b9pKUxGotgOgeXDGk Message-ID: Subject: Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC To: zaartur@gmail.com Cc: Nikhil Chawla , Andrey Borodin , pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000f96b90064e796de6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f96b90064e796de6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 30, 2026 at 6:44=E2=80=AFAM Artur Zakirov w= rote: > It seems we don't have ways to enforce this rule, and a user doesn't need > to have advanced privileges to run PREPARE TRANSACTION. Correct me if I'm > wrong. What if instead of adding a GUC we would add a new role, only this > role (and superuser) will be able to run PREPARE TRANSACTION. > Well, it is certainly a better solution than a global timeout. But there are a ton of other ways that a user can mess things up. 2PC is very powerful, and very hard to get implement. It is disabled by default for good reason. Someone enabling it needs to have all their ducks in a row, and should have their own ways to monitor, and handle, errant transactions. So a strong -1 from me on the timeout, and a weak -1 on a GUC/permission solution (which could get hashed out more, perhaps). Cheers, Greg --000000000000f96b90064e796de6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 30, 2026 at 6:44=E2=80=AFAM A= rtur Zakirov <zaartur@gmail.com= > wrote:
It seems we don't have ways to= enforce this rule, and a user doesn't need to have advanced privileges= to run PREPARE TRANSACTION. Correct me if I'm wrong. What if instead o= f adding a GUC we would add a new role, only this role (and superuser) will= be able to run PREPARE TRANSACTION.

We= ll, it is certainly a better solution than a global timeout. But there are = a ton of other ways that a user can mess things up. 2PC is very powerful, a= nd very hard to get implement. It is disabled by default for good reason. S= omeone enabling it needs to have all their ducks in a row, and should have = their own ways to monitor, and handle, errant transactions. So a strong -1 = from me on the timeout, and a weak -1 on a GUC/permission solution (which c= ould get hashed out more, perhaps).

Cheers,
<= /div>
Greg<= /div>

--000000000000f96b90064e796de6--