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 1wZQk2-00125U-2K for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jun 2026 10:09:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZQk0-00GfQC-25 for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jun 2026 10:09:56 +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.96) (envelope-from ) id 1wZQk0-00GfQ4-0k for pgsql-hackers@lists.postgresql.org; Tue, 16 Jun 2026 10:09:56 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZQjx-00000000i73-3ZeT for pgsql-hackers@lists.postgresql.org; Tue, 16 Jun 2026 10:09:55 +0000 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-490b4a8e28bso32070665e9.1 for ; Tue, 16 Jun 2026 03:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781604591; x=1782209391; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=oMiIuhCyCaoakbRb+4oSlsohlyrdp5g58vdLOJDbiOU=; b=SJB/jAaAhWSAZNnOP9vzzlpC9COy5zhoLJcELsmiuXDeJGmWMetmjWIyIlyxOLv+M7 9yLR64mkie1oUyU3jaWFXDZeV46VvA4V34H1tx90aXfVPYEJe05by3pX3vMGO7oJ+zc3 9XzkhFV+oOPeNm4+dAzAsna79Q0ngppessunBCqlLv+2e6ZtqAL0UaGIXiKNpWJ1hRem bbcsX44zp7HFV6VA/IA0XRjXPjYmeNhsLTA1EVkPDMxhCxCuk0oepn3T+Dhc8IpItT/a KUr8ZJweqezwX7RHhK6/ZTux4uqMK4/UV/nEmfgYeZNFsZ7rFMKR9wbYpXGJKqGoxSHU kxSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781604591; x=1782209391; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oMiIuhCyCaoakbRb+4oSlsohlyrdp5g58vdLOJDbiOU=; b=HpjETkEqOzNjn9UQcif/gK5hJhkIMV0hgexKoKGotfXHISJOU6OnsRoY5z50uko/lc aF3mirak/Jj+FfIZ6xDcNIr3qfdSNOfszqmi08FkGs4TnU9QgZvd+Mmm2TAhPai38/+z J96AlWpF4PGaBTq7sf3wRXY3kxtS1xBjRTlkahNhiv/XbKwkzmF3KhoUORQjS+DUEtmK J2o0UdODSqmeWVz/39rR2KJZNN7laI6IMRaFG0IMuZHoxmoRd/v+izDolZ/zTdH6doio AJkALps5+g7p3HUGXvwd2YCB6HAT95Jz5iZwHZNpF/9gErabL4NI8F4a+hSgN1aN43yO n8QA== X-Forwarded-Encrypted: i=1; AFNElJ8ODa0xbeOoKE+gPT6RWDHXc3Fn3ZN9bWH/Y6twTyjHQdzAoM351GqrKrrI1xex2chSh3w/L5zjR8Y6ma6n@lists.postgresql.org X-Gm-Message-State: AOJu0Yx9/sHO0d1iDWLCfHemFevkNt2OJCMA1654GKQdRIknZ67MLX0z 6bXQdJGgvmlk8lN3gHqKRPRcqgwieUQoakJzBEKfIAm10TC/EDWAvyds X-Gm-Gg: Acq92OFF9nrRe30GtGYwUDHU1AlnaNqD2kLXMVMux9ICwyJjvbH0eDLvw3ZTzV0XtxX z2SDAOLd7sBX86CyMFdU+R+m0RBnsHdmDWIRCfwCM+G13n9AZkoTd24+p7LNdfvgwVYlu0zGI+h iTjKgzmyw64YR3VeKzUUzuohn9o2U3lEGJ4OVLhyGxPP5cuBrHRXQ/mahfXY3B7BXpo1yUZ7elW lHTwnP6YgpnqVZ4TltRL+lkOxGhgB+KqvWszDhPertmsKJdhyGqui3lgGL+eKbpH2ydFWu7erKA sg1sNO3a61YiHLb16ATcSWLkuYVjroNhbmFs1lKsgaLLmkhpghQPopuwVUx+zYr+lZeucvs8528 TyftgcUVoQhexaMN1DDrwYr8pEUJC5Qg8R2pUI/UPYYcYExX13EzU2LhVPLNL0rCfHkJmxA4Xu0 Bhb3ao6fSp5DG5FPs1D0jSWgNDv0GlC1Rh/eFOKwGprNBFR1NS6ivbtApKlb8KrWzoNgFA5wp7w exBkRZdMTc= X-Received: by 2002:a05:600c:4ec9:b0:48e:5fb8:f80f with SMTP id 5b1f17b1804b1-4922ffb656amr42834795e9.24.1781604590391; Tue, 16 Jun 2026 03:09:50 -0700 (PDT) Received: from bdtpg (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4922fa510e7sm78006805e9.7.2026.06.16.03.09.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 03:09:49 -0700 (PDT) Date: Tue, 16 Jun 2026 10:09:48 +0000 From: Bertrand Drouvot To: Jeff Davis Cc: Heikki Linnakangas , Robert Haas , Roman Eskin , Michael Paquier , Alexander Lakhin , pgsql-hackers@lists.postgresql.org, Tom Lane Subject: Re: Avoid orphaned objects dependencies, take 3 Message-ID: References: <3963e573-4852-4d25-b741-7c5c7e1f9140@iki.fi> <02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com> <71eb9a8835a28165939da567a9d649fe6d21bfa7.camel@j-davis.com> <0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="uRwkvoKSj2xIjEZp" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --uRwkvoKSj2xIjEZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Mon, Jun 15, 2026 at 06:19:19PM -0700, Jeff Davis wrote: > On Wed, 2026-06-10 at 15:16 +0000, Bertrand Drouvot wrote: > > PFA a new version of v26, it adds a new test as compared to the v26 > > previously > > shared. > > I'd like to avoid adding lines to AbortTransaction(). Also, I think it > might miss subtransaction aborts, which could be relevant in complex > cases with SPI. > > Can you use a structure like: > > ProcessUtility() > { > TrackAclTable *prevTrackAclTable = CurrentTrackAclTable; > /* allocates in CurrentMemoryContext */ > CurrentTrackAclTable = NewTrackAclTable(); > > PG_TRY(); > { > ... rest of ProcessUtility ... > } > PG_FINALLY(); > { > FreeTrackAclTable(CurrentTrackAclTable); > CurrentTrackAclTable = prevTrackAclTable; > } > PG_END_TRY(); > } > > That would avoid the need to create a special memory context; you could > just repalloc() the chunk allocated for the table. It would also mean > you don't have to track the stack frames manually with a counter, just > use a local variable. The advantage of v26 is that it also checked for the outer while checking the nested (that way a revoke that impacted the outer would fail sooner). That said, I like your idea: it's more readable and probably less error-prone (don't use global variable in multiple places and a dedicated counter for nested checks). So, the attached implements it that way. It's in 0001. The reason for multiple sub-patches: > Also, are you sure that the two call sites for aclcheck_track_record() > are enough? Or do we need checks in e.g. pg_attribute_aclcheck() as > well? Currently, the only caller of pg_attribute_aclcheck_ext() that also records dependencies on the checked object is checkFkeyPermissions(), which already holds ShareRowExclusiveLock on the referenced table. While ShareRowExclusiveLock prevents direct REVOKE on the table, it does not prevent role membership revokes. So 0003 adds pg_attribute_aclcheck_ext to ACL tracking for dependency recording, which also protects against new DDL callers. The remaining aclcheck functions (pg_parameter_aclcheck and pg_largeobject_aclcheck_snapshot) do not need tracking: pg_parameter_aclcheck checks GUC parameters which are not dependency targets, and pg_largeobject_aclcheck_snapshot is only called from inv_open() and has_largeobject_privilege(), neither of which records dependencies. That said, while looking at checkFkeyPermissions(), I realized that we have a corner case in 0001. Indeed, checkFkeyPermissions() first tries pg_class_aclcheck() (which fails for column-level grants), then falls through to pg_attribute_aclcheck(). But as aclcheck_track_record() is called for both successful and failed checks, then the tracked failed entry could trigger a 'permission denied' in recheckAcl() if catalog invalidations arrived between the check and dependency recording. 0002: fixes it by moving aclcheck_track_record() to after the permission check succeeds in object_aclcheck_ext() and pg_class_aclcheck_ext(). Indeed, there is no need to track failed permission checks. It also adds a test that reproduces the issue by injecting invalidations while the FK creation is paused after the failed table-level check. The test would fail without the fix in 0002 applied. 0003: adds pg_attribute_aclcheck_ext to ACL tracking for dependency recording. It adds an attnum field to AclCheckEntry so that recheckAcl() can distinguish column-level checks from table-level checks and call the appropriate recheck function. InvalidAttrNumber means whole-object check. The sub-patches are to ease the review. They should probably be merged before being pushed. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com --uRwkvoKSj2xIjEZp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v27-0001-Recheck-permissions-after-lock-acquisition-in-de.patch"