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 1wXI5T-003B2T-0g for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 12:31:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wXI5R-00BKr1-0D for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 12:31:13 +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 1wXI5Q-00BKqt-1R for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 12:31:12 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wXI5M-000000020Wn-3I56 for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 12:31:11 +0000 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-490b7866869so73781175e9.2 for ; Wed, 10 Jun 2026 05:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781094667; x=1781699467; 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=sTvEY+O6jWgiiDqFLVnsqZAZXpqbT7QVzXaZQwNK+zY=; b=jmUfA5uGzWsZUYiLPDp7tKaAWJOXNhESd4U5xwja8+XWnJOs+qMu0SaF/EjJ244Fyd uiY+CKNsDjDYjCNyPOr4SGG5my3JWgQgqDmhFlSX64gYOgStxas3U3VWBESLEoFid4ON lcDB2+BUnpD1j4Pv4NxETvZfkqVI1eSQ2XQvIptwxSZwPUisr/GMZR9PeAtLPRq8x+ZY KefAV1HlkXgayUzGrglQQhK2qOymvbTF1geK2lSfG9/hXScimwCHN/fWpMnU8V15hsaP 16bCjoJc03QnhbEQYicAFjmcDhPY9pvC571Hv5b/WloAWHLTcoPbWu1524vNMPInlulV 4XBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781094667; x=1781699467; 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=sTvEY+O6jWgiiDqFLVnsqZAZXpqbT7QVzXaZQwNK+zY=; b=fW9APwt4UVzaaT5OgB0yQULe+AitQW3HUgPQnXGrglRFqm3fVFS+b9LFN/+WZkrGaN i/6JvCi+ZJvcMEb9Kndls9e7dhLPwuzvY3tsZwVh4y5zm4tI4uZYTSDpYNwUk1CUOzzM IHL2x/ohfV75XGBJWD267tLnEqQiYG4fCiY/zwu7oFzKqUwVzbz/r6+4etjxj/KV1ggi CoPiJhyCuCtgFWLmtZQt7RHnHxhDIk/UFXzAIIuBsvAGvE2t0Wj/83mCbmCzxjia87fc o5B1Onp7pMCrIvo47L+XdJGJ08mbJYErTeQdPcqZk5CZPi7/6zkRoxgMPZjZ90nAHahm 4jPw== X-Forwarded-Encrypted: i=1; AFNElJ+i9B0nRbVWA+8/XWo7b7kWYxai3zcReodhAVXJiWiPopDbSbWEb6ziKcfcHqn0B76h7GOcvy44ZkuNGY4a@lists.postgresql.org X-Gm-Message-State: AOJu0YyEfSNyqDQkG2imXcTrxuo0uZC9a1MPlTW4GVMTIuZNG9d05VKA WE5h5Zjj101tHOvcIoGjHWb/I0gBL6IuGAyQfbMnqmqnHcgMlFU14v8l X-Gm-Gg: Acq92OH3FrD0J+y7dgZJyGpUnSLHC1xqA4PzulzK2gZeaWuuQ9iZkEYy1pSVslg9Fq+ pM5ZOcxak0ZRMT9CVzYelUHuizXw2WF5iWAlcpcWD0NFUCGH4ptyAMJPbbFh60aUOkYDs+AxFkj jYqgFb4ZuJyt/YeXdzjiE2A9aDKzwJLhYpkSPShod6/JTLNp0r6N8J3N+ZwiR4ovunK2nDy2H9N IchGCmus35a9fGRijDulkASsxnoB4/QG0tpq+Ajh7/cpLhTKYRR3r2/CGTcWNobrr+MZYqGLfF4 ShZnfnhREjzEhGF3am+boaYxauqzCcY5sZQVt7GUexeztEQ645WdiAGt3GqVRjY6uJaffQRfl9Y 5f5h95mgAgXAUPzM170YJqjgKQaqWSuzIWQOxUqXu9Oo6F9TNlt9eKDftAqhp4RZUfDeSSoAIjM s/OVgn4VPO/C07FXUgvCpvfJmXQWli3xV/H1tQQXQYdPbcf0oVjsZgsRXeeJxFk55VBthfITKHC mhmydghqLIQUVAxPLmNSA== X-Received: by 2002:a05:600c:528c:b0:490:cdb2:fb5e with SMTP id 5b1f17b1804b1-490cdb2fd19mr232363125e9.22.1781094666976; Wed, 10 Jun 2026 05:31:06 -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 ffacd0b85a97d-4601f2e4004sm71744117f8f.9.2026.06.10.05.31.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 05:31:06 -0700 (PDT) Date: Wed, 10 Jun 2026 12:31:04 +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="HMAKO4gjDTq7S4gl" Content-Disposition: inline In-Reply-To: <0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --HMAKO4gjDTq7S4gl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Tue, Jun 09, 2026 at 02:44:10PM -0700, Jeff Davis wrote: > Hi, > > On Tue, 2026-06-09 at 06:47 +0000, Bertrand Drouvot wrote: > > In order to be on the safe side of things, the attached now iterates > > through all > > matching entries (and not only the last one). > > I don't think: > > if (context == PROCESS_UTILITY_TOPLEVEL) > > is quite right. > > In any case, I don't think mixing the tracking entries between entirely > different DDL commands is a good idea. If you execute DDL inside of SPI > in its own subtransaction, and it inserts a tracking entry to recheck > something, and then you roll back the subxact, you don't want the > tracking entry to then cause the outer transaction to fail. I didn't > test this, so if there's something preventing this kind of problem, let > me know. > > We probably need to track where we are in the stack of ProcessUtility() > calls and keep the tracking entries separate, and always remove entries > from that level on return (or rollback). I think you are right. I changed this in the attached so that aclcheck_tracked_count is saved on entry and restored on return of each ProcessUtility call, so that each nesting level's entries are kept separate. Also, the reset is now done whenever tracking is initialized (means at the outermost ProcessUtility call that starts tracking). I think that addresses your concerns and it also fixes the issues reported by the cfbot (that I mentioned up-thread). I also added more tests related to nested calls. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com --HMAKO4gjDTq7S4gl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v26-0001-Recheck-permissions-after-lock-acquisition-in-de.patch"