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 1wZZEq-0018hV-0s for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jun 2026 19:14:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZZEp-002JiU-0i for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jun 2026 19:14:19 +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 1wZZEo-002JiL-2S for pgsql-hackers@lists.postgresql.org; Tue, 16 Jun 2026 19:14:18 +0000 Received: from mail-oi1-x234.google.com ([2607:f8b0:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZZEm-00000000mcT-1GtR for pgsql-hackers@lists.postgresql.org; Tue, 16 Jun 2026 19:14:18 +0000 Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-486badc02ecso2142721b6e.3 for ; Tue, 16 Jun 2026 12:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20251104.gappssmtp.com; s=20251104; t=1781637254; x=1782242054; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=HKxmgdBufgzw3jJszq9PtYAK/JcyAUNDi/LTfvJBgzs=; b=Db43aB3LeYfObdSzE9m+x1E1gR2HAs7nH9F1102O0vvhYYL+IHk9dqOkUpPcisdmrs +43M/TfG69xwQW/Na2QfRMZMQV4OosaZlqhdFZHEx5XrZPTs8/dMsuq46iWkxGphStNm 0sbqyvKWIS5HSLwpDWYV87wJq8mQ7hP3KkV2FwwqnjS7KenJhyR38/DGbUvSpOubZf3o EAqN/4EkSWg+w3IoAozvmN0D/zI33Rjt9VfTcUsNEQx0kYRCBAM4IMKcwGOazjFT0kX6 jqOklyL2OrfzQdEUrACTGKMBV2h9wBoMk5EMaDecwi1hqKhCC5wKlNEY/klNHdjeJdn7 XArw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781637254; x=1782242054; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HKxmgdBufgzw3jJszq9PtYAK/JcyAUNDi/LTfvJBgzs=; b=MSYtiIOXIh3RAboHmFoeE2nTz+SSliGUwYVWIqnTvY3kRO+To2IMDRLRVHCXxNiZty yYkHBbo6B93UaVadkhMhANMw9CvlvO784bfx7ydbsGY8nIli0RNHECgPXAVlSPOj0+/j /NBLXyS4oNbbPWuNzRCCAZRVmLPdhbB89ChiadPPn9iOpcr6rzCTysmaJXQpUDhfe+Cl 8+mYjctUQYHgWLzidlpCtIKPX+ri7ng1AZT8zp/WFqOax+8iT3kmosfAhYmHqidOr20a 1cwUz8rWvXN+Lj+1rOMi1Vm5PghswPhKOnYNwNiHhv8CvzrnYW8p27urelK32+ZCDcFw nNGA== X-Forwarded-Encrypted: i=1; AFNElJ/4S4UQBEzGRzY0xS4iLPqi5XeFGFZyyEr14n7bYKDuUECQ1VzUqiBP1M1M/hGduIBQAFdxkNbvf5EPHOiq@lists.postgresql.org X-Gm-Message-State: AOJu0YyjFgb3MiGrjH3S6oFg7hqCKfm9kVDGXKw2w2qcpyZCu4kTh/h4 aamonzjBlnUGAiV8oGBOmTDpIuuD0Zfjl/uL36RR1VUiZH1ftvlYxbAR4dHTQMe5fA== X-Gm-Gg: Acq92OG86nec7fLTy5nvV7Cr65gG4zj3DyRY3gU1DsTDJREO1eoH6OTGaxdhFQW58DV ynnw5w7agt4dBYJ/XHqtu5UM2rBx3uDOg68DmrkEgUHc+bCZ4+zPPgVAjV0KIaDsSJETipQYv25 BPNbGzMxF3M9+kMrEH2dyp8uOW38yxpfVgn8856jyf0A/EL3rzPpeKY+8guCXsVtm23+KtfD+qX AwBIQeLMRUf/iEcZqW3sW1OWyt+U2uYtV4wVSpEaZSAJgiSAtpezRnKedsQOzDvVcrrnnQsVAwE EG4t+PmSkitWPnU62aY6E22HtbyHOlzzH+JWZ4ADvFjVbB2Nr9EvMKyWzn+rHtrjGMAdwTelHli Ce/ltZAql/f9GWXVCZ0DKEIXT91IXJIjXtbgw2EF0OHpb7jDbMDzPzJxC0xIYmlR6R1QVbG6zFu eaq9oXKfHpmJHucSEug08a6YA= X-Received: by 2002:a05:6808:3022:b0:464:5f3:ed1 with SMTP id 5614622812f47-4894460a8f9mr353977b6e.26.1781637254399; Tue, 16 Jun 2026 12:14:14 -0700 (PDT) Received: from [10.10.245.117] ([12.63.242.123]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4875dda5f7csm4915357b6e.1.2026.06.16.12.14.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 12:14:13 -0700 (PDT) Message-ID: Subject: Re: Avoid orphaned objects dependencies, take 3 From: Jeff Davis To: Bertrand Drouvot Cc: Heikki Linnakangas , Robert Haas , Roman Eskin , Michael Paquier , Alexander Lakhin , pgsql-hackers@lists.postgresql.org, Tom Lane Date: Tue, 16 Jun 2026 12:14:12 -0700 In-Reply-To: References: <3963e573-4852-4d25-b741-7c5c7e1f9140@iki.fi> <02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com> <71eb9a8835a28165939da567a9d649fe6d21bfa7.camel@j-davis.com> <0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.3-0ubuntu1.1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2026-06-16 at 10:09 +0000, Bertrand Drouvot wrote: > 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. IIUC, this is necessary for correctness. If an ACL failure doesn't cause a transaction abort, then there's a danger that we cause the transaction to fail that should have succeeded. So the ACL tracking needs to be precise: we can't track an ACL check unless a failure always causes transaction abort; and we must track an ACL check if it would cause a transaction abort. Right? Regards, Jeff Davis