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 1wVUIz-001zvW-18 for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 13:09:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wVUIy-00CYPO-0f for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 13:09:44 +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 1wVUIx-00CYPF-2B for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 13:09:43 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wVUIu-00000001EzD-3oE1 for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 13:09:42 +0000 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-45ef82204c6so1064161f8f.3 for ; Fri, 05 Jun 2026 06:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780664979; x=1781269779; 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=ka3wb47xrwTLknV2u6S4cfVMCIM/osBXqK9OtcXAJgk=; b=Rp2MjTlXHWB6gz3BI0oL72gq136jnhtBZ4QBFXTt9R0J2d7pSg1l5oQBIKfQnSj72D Ye2h3Th9YMEG5ev5NL3xONswDY/v1QVwI29QJZa7UGrh/5aXT6q3iM52ERph2p00Hvu+ l2P8vZuu4Fi1bQ5QtZ5GtEg21xJn7s03UKgI5xgP7h4eS+rmdKoQmM1ozWfIUJPVA4UG bkmFxVj3q9faZTvlzWFeiW3ytB+O7dKvkyQL+2p5C3TEHIQRPefLykznqulB2HSvMG1T LoL36rn6B/KA4ijugFWOcvznJyGUEGIEfFX6pPizh0uXpeVcWOuc3z0TOX5VzlBd8UN3 8EYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780664979; x=1781269779; 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=ka3wb47xrwTLknV2u6S4cfVMCIM/osBXqK9OtcXAJgk=; b=IB9uNIksREi5a72XsbzWnVu0pf0s9Xoyn5H8ZVQxW8wDfqw4GGwPMHjCfQN2IaGZEE AnMo1ouPtiC6QB+LKoPIesgefIewOzfMIFINW4mR7RrFePWZ1ch5rPWK8v+MDfaaXE1y nxkpqDZycqFR5LJNcmcHI8OQkqGTybrsLbplu5b/nj/W+OaJxqojupaM+7IlueJ3pmGK CdR/Ys/8JouEHTbJ2ZCF9sqWYHlX/tnkv0tIx84xldNiuTAMksj5L+pQjX1tHmBfojgA C9Z249TZ91ielVvsxBcMyYzlxRLPr7O14zbJ3dgvAeCAmeTuHWXDmUcDsvbiQIERwBKn y9dQ== X-Forwarded-Encrypted: i=1; AFNElJ9lj1P+3AvPR/PU85a0RxKlBozFWN8NVid9uuVmP0Gq0Hwxq8s12SUDJ4RbVwTdQ7mBCLYCbJFoAkB98CAF@lists.postgresql.org X-Gm-Message-State: AOJu0Yyzgze6P9ZbqAi84UGuNlvw1ybpmfxOwhJKi6YXhcM85pKCKqpe uNuckxx8gHoath5BV27u9x/mAgypVFcn9GqDnoknCcYVMSbyexl85SJf X-Gm-Gg: Acq92OG3uvAxPURfdrWq6UuY5x7xxAU2og06M8EERdqjnSyvwRgOCCeRJjn9mU85/6T 4k8oJhOstGtqZBR/+zg2jHuV3Ruv4h52nYBZNBDERk79Ghg5m8ycTmU9OhijnS5gCIyNC8IlPST +J547bnPiJNLR3cjkKpt+s3RYAK+KJNG0OILLHz5e2beHbHCNr6+K+o7ZycNZG5H37fHT32Pf8K 5XSQpfm6oJWDIXaTZk7eyvlwts8Qy9nYrXubXb1xEFPP+zjEj4GXyI4+gcq/4BrESSBBGdvEnHS XTKFqG/p6zdlTyMRJkd48vYlaPbPws9+OwFrTAJYTZTFMwFrOKCpS4iyd0rxZy0u2Hv41cnbCAp s8LbvrT2IzE2ctsylMLN4AWfbLK4CgO8xK8LVL1DMJpNDfigkdPV0PMyOZxFsLGe3c9iCrh0Se5 LSDWon43PscWP3l6CRXJOCrtxvooMwOJe1CZ57/l/9UqXXBKNdNJM9DCmoMZuT44qZPQGEWCVcw aZF8RDMQCoFuTb2a0knVg== X-Received: by 2002:a05:600c:3e0d:b0:490:a1dc:e542 with SMTP id 5b1f17b1804b1-490c25afe6bmr56640405e9.6.1780664979243; Fri, 05 Jun 2026 06:09:39 -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-490bc3a87dasm143022995e9.7.2026.06.05.06.09.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 06:09:38 -0700 (PDT) Date: Fri, 5 Jun 2026 13:09:37 +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: <9f5f0dd4-96d5-4d90-9436-62d96e0298f9@arenadata.io> <3963e573-4852-4d25-b741-7c5c7e1f9140@iki.fi> <02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9vJ2bamBnv+Gh0A+" Content-Disposition: inline In-Reply-To: <02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --9vJ2bamBnv+Gh0A+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Thu, Jun 04, 2026 at 10:03:22AM -0700, Jeff Davis wrote: > On Mon, 2026-06-01 at 09:21 +0000, Bertrand Drouvot wrote: > > The tracking array lives in a dedicated AclCheckTrackContext memory > > context > > (child of TopMemoryContext). The context is reset at the start of > > each > > top-level utility statement, which frees all prior allocations and > > provides > > clean lifetime management. > > > > Recording is gated by aclcheck_tracking_active, which is set to true > > only > > during top-level utility statement execution. This ensures DML and > > queries pay > > no cost. The flag is cleared both at normal completion of > > ProcessUtility and in > > AbortTransaction to handle the error path. > > This could use some better high-level comments in the code. Something > like: > > "DDL performs ACL checks on referenced objects before acquiring a lock > on them. The lock is acquired much later, when recording dependencies. > Track the ACL checks, so that we can re-check them after acquiring the > lock. Agreed, I just re-worded a bit to add some nuance in v24 attached, as: " may perform ACL checks on referenced objects without first holding a lock on them. In that case, the lock is acquired much later, when recording the dependencies. Track the ACL checks, so that we can re-check them after acquiring the lock while recording dependencies." > XXX: consider refactoring so that we perform the name lookup, > acquire the lock, and check ACLs all in unison, like > RangeVarGetRelidExtended()." I like the XXX, as I agree that what you mentioned in [1] is an area of improvement but not something directly linked to the TOCTOU issue that this patch is addressing. FWIW, with the scenario you described in [1]: - before 2fbb21170e9, the function would be linked to a non existing schema - with 2fbb21170e9, it produces "ERROR: referenced schema was concurrently dropped" the current patch just "keep" the post 2fbb21170e9 behavior. [1]: https://postgr.es/m/5315d15a42109297259d1a3264ad09e363eb98df.camel%40j-davis.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com --9vJ2bamBnv+Gh0A+ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v24-0001-Recheck-permissions-after-lock-acquisition-in-de.patch"