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 1wUq0p-001Tzi-15 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jun 2026 18:08:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wUq0o-002VeN-0g for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jun 2026 18:08:18 +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 1wUq0n-002VeF-2g for pgsql-hackers@lists.postgresql.org; Wed, 03 Jun 2026 18:08:17 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wUq0l-00000000wqM-47E6 for pgsql-hackers@lists.postgresql.org; Wed, 03 Jun 2026 18:08:16 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-440d9bfa309so1139573fac.2 for ; Wed, 03 Jun 2026 11:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20251104.gappssmtp.com; s=20251104; t=1780510095; x=1781114895; 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=8r0YJb6njk22POwNZNm/yD+F0sztxe0MtOgr327lk3M=; b=Z6wCSaKfRWnRJhTJEcAq0rqrveDSlUwf6v/AiS4z/dqt0r5NFYGDg4qWaM8aQaNP2t ZOtOIUc6Ueg1syiKsvVKOCLTRIgFNQMF+8wB1S9G9E0J1VOWV4737BH0H/Zgfd8RYDoM 5Pr4apmhUfOvxYFFEDq7GK7mo1Ln6kkuPqARJaKW6LhmhkWewerP1PWlPXUyca/2ZNwp 7eX8BqpP7SqOqiwKaQMM54rajG4PqxhLarzFJodtMdojeuL1W6iu3JgOo/jmpG5OEwVh DAsYq7uUETLhqQdSgqBvuBWZp8Gs7Mwkp8GvzIcEYaJiBh0QelTLKifhlvMgAb5RJKZo RWjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780510095; x=1781114895; 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=8r0YJb6njk22POwNZNm/yD+F0sztxe0MtOgr327lk3M=; b=dLbWyJbuNjtEGr96ex3R925XFoQMxlB3hLVL+gMs1zUxjsNixzGRyYlEQ9FoaE0ww4 1qCB5LCVJLSYLkD93NsPBC0eKIMnBA8Xu6HwPqCoo52CzJVaomu4i2U/WB5Gmv5krjDl zTziS/VkV5HiV3gpHDGKYMldUnhw9Ksg9AAB3yzjrY+CVDqv2FRHCnWGVuIgBxvcMs2N UYFHz7oJ1AbXz9QlPmieySlHvun7xbyWvMGsCqfD2EXKwDOv6yNN3bCQ7niYqDl3uCSH LuL4y27nyGKul5M8cTQMJJUhmMpC+e2g7E+U6l36SOg+B/pbMSiRbjzzLwCAtQ/t0pNz zzDA== X-Forwarded-Encrypted: i=1; AFNElJ/B97QsFm/t7KZFJQBhqfzYrTJ/LNU24XqZAGHgbkfUM1z0hZdvccHbWckh49rDNqVC0AwDI2W4klXJD9si@lists.postgresql.org X-Gm-Message-State: AOJu0YwhPI62dFVHlf5g1/M6BDTXiFnJncCrXP0aUKtu48hppAl3H3qJ 9mbsdI2Vpwe3qg23a8hhMBdRkwJzC56TkuNTfJgK8VsJ90WZjkrVMCSBkjglLHnjxQ== X-Gm-Gg: Acq92OG2nEOinGk9svMtdm3wi8jnsWOJUNSDRE6vVAwc0BeSGFwmR7hsW53NbD7d+09 2CyndEBHB3L5JpBhjMRipgJlsQDuY7qIbtHKbVuk08sOaxbaNXVxuwwYMnYSJ71G1fGSb0BKOJZ U5fsaOQlLwEa7MwWHysDYSn075Vg7oJnrlJ9w7OjuLT1ghGejm+NIhvYvKFpVY6uSNs4T6X2dOf WOTcIJ7njYK6vSKDzV4GgdX4p1Ebbg2lhX6ajPO19DKisznqXVUzxjC12HM+Xnxc4nzkmqYdQo5 RGL8mfdUH8Z52JiYr7ubd26rXhq27uGS7xPfmiQdTKFlpf6zLKzCWCoaXz/R7ogJYfOKx2OhCg8 L7v0CL08nIWIUgEM9QafXP/zmW8s/4tKMGKC2dzuIRhRSRFHZ50Ie/45xFoPAvR5MXYkS8/RlPy fJvs3f/tpf3U0kRl055m8MfUUK8BVm0Q46+w== X-Received: by 2002:a05:6870:b296:b0:42f:aec9:9d92 with SMTP id 586e51a60fabf-440dbadcf5dmr3591925fac.29.1780510095250; Wed, 03 Jun 2026 11:08:15 -0700 (PDT) Received: from [10.10.245.117] ([50.175.226.10]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-440d7263efcsm3335137fac.0.2026.06.03.11.08.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 11:08:14 -0700 (PDT) Message-ID: <5315d15a42109297259d1a3264ad09e363eb98df.camel@j-davis.com> Subject: Re: Avoid orphaned objects dependencies, take 3 From: Jeff Davis To: Bertrand Drouvot , Heikki Linnakangas Cc: Robert Haas , Roman Eskin , Michael Paquier , Alexander Lakhin , pgsql-hackers@lists.postgresql.org, Tom Lane Date: Wed, 03 Jun 2026 11:08:13 -0700 In-Reply-To: References: <9f5f0dd4-96d5-4d90-9436-62d96e0298f9@arenadata.io> <3963e573-4852-4d25-b741-7c5c7e1f9140@iki.fi> 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 Mon, 2026-06-01 at 09:21 +0000, Bertrand Drouvot wrote: > Now that we avoid orphaned objects dependencies, I resumed working on > Robert's > concern about the TOCTOU window where a REVOKE could land between the > original > permission check and the dependency recording. >=20 > Based on our discussion during PGConf.dev, PFA a new patch that uses > the same > approach as RangeVarGetRelidExtended(): record > SharedInvalidMessageCounter at the > time of the original aclcheck, then before locking compare the > current counter to > the saved value. If it changed, recheck permission before acquiring > the lock. > After the lock wait, if more invalidations arrived, release and > retry. RangeVarGetRelidExtended() coordinates three things: - name lookup - lock - ACL check whereas recheckAclAndLock() only coordinates the latter two. That means there can still be some strange failures, like: -- Session 1 BEGIN; DROP SCHEMA s2; -- Session 2 SET search_path=3Ds2, s1; CREATE FUNCTION f() RETURNS INT LANGUAGE plpgsql AS $$ BEGIN RETURN 42; END; $$; -- Session 1 COMMIT; -- Session 2 ERROR: referenced schema was concurrently dropped even though no schema was actually referenced in the query, and a retry of the transaction successfully creates the function in s1. Is that expected? Regards, Jeff Davis