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.94.2) (envelope-from ) id 1v8OGy-00HP7N-TH for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Oct 2025 19:31:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v8OFy-007QjE-JO for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Oct 2025 19:30:55 +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.94.2) (envelope-from ) id 1v8OFy-007Qj6-1M for pgsql-hackers@lists.postgresql.org; Mon, 13 Oct 2025 19:30:55 +0000 Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v8OFv-001Zzi-2m for pgsql-hackers@postgresql.org; Mon, 13 Oct 2025 19:30:54 +0000 Received: by mail-io1-xd36.google.com with SMTP id ca18e2360f4ac-92790f12293so215507139f.2 for ; Mon, 13 Oct 2025 12:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760383851; x=1760988651; darn=postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=RW7f60l/0woodUlFiycNnAyBXpzVBNVaIoRxAvAhpRA=; b=YmfPB/cvdU5dKBN7/FdW33QLqcx8uO+3Nw4veC8JMWo5Qojk/tHqh25b+ORdxVu+El 8DjcBX1sjWAORcBemdsip3ch9DbthOWZadA9C5SemRccZtkRDEDyljSFxgepvv3h35p3 xbAW7IZDW4GDZBFWoVXJCOzfIngNZQAanc51peclNAfrios3bBsMBzvNxqYG4rszwN1K 1GLgijS7I0hTFBU30ZV+52len6rPRs2ykE3FRZ4/LP1KaCobK1CcOPOdqce5Lhp4yK9H zwI5a1rwMK1lxIH3oRJkehTRa0gonMWln63GImAIWklgIN8Z7y9o2dW0DXfuUF/N1+WF 68Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760383851; x=1760988651; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RW7f60l/0woodUlFiycNnAyBXpzVBNVaIoRxAvAhpRA=; b=or9uDP7NINUvX26wFD9RIQVf8Vhp7q53mEnJUW5OZxD3VYrwFZFovLjPU66b8B9H2a el42O/q7av9GSvzebhFwmdTTYWh0i7mrzAwz8RmnrwT7bFzntWjfw6sipD2cvpQs49Ig K2YgPtxQfvuOnzUyX1+uouftqT83nF1V9HYH8Jqp8UTdTK6vtWKO09cqnpNHkBuaAJXm 59F4kXQw6KHgUxI8qNI6yXHBSYWio9g+/eL1IxJ3trnIyLyiVdOu47DdEQ5OtFZnR4cz HMtILqAt5dlMveE4oeBmnfR0g4GwjGaPRzCk6cMBLc6dSHSREpSBiF4c37AjDQtj4IH/ enbA== X-Forwarded-Encrypted: i=1; AJvYcCXu77LdRMuIX1rMg2h/vTCl3aS0+RlJkJmCpbiwJR7eVD3Q9tM/Ue1fSD7+7LXhrttyYYYhsi1WOIYZj6NP@postgresql.org X-Gm-Message-State: AOJu0YybUf8w8LbV1EwG4XE9XNxXdhfA6F1k3KP3tzEV0L71biB/9RG8 GB+Vj4E7UN9L3mXnro5iwa+gmu1afvlC6U+oTr+5VZeN56UwFa6irjuS X-Gm-Gg: ASbGncsNdf8lELo7nxrKla5R5qpJYEtsB9Vg10dAP6TZ/D0es2/wr5Op9fe6dKWtsZa HoQvNkDbH4WNtLK6xoc2lpyvrWa2yWvS5aE9q2x1DvCwafG9j8BpVMn9i3MYOg7rHDsxCjimZNH e4B1mFMraHA4jzjjO1/dhG1oVhf6zKku+CuTUmMXdtoKyV8FZwr5KilYeq47oCOLERiAWNnUjiz yltrUNY5m3ETff8fh/o7xlAUq6dVbq5QsbjIxtuOfdoJGW1WqR3BZX40aF5iT2lDDD8ydqjOoRm bfBmtkinKFy61zZZPz+GBt1aAoviw5upaW5koBbhunJMd3qJ4NwG6AtAhiUtf9maXFUAb2WXDAF fizslpKjxfi4uwv558rFLnWZ9gY6eiXYCTVbE4sbHHrBeYykhcOs6jvPcicmebH48RKq13/ISPa BYaqNwDypaiyM7/KezBpktn/7fOz1Cpys= X-Google-Smtp-Source: AGHT+IGy04YeHp7MKW4eNsuaZVeCzndNOcRB2cLu+UFq7wNyv6mZGJAss+kDMnz0mVGU/824tzQNoA== X-Received: by 2002:a05:6e02:4918:b0:430:9bc3:e1d3 with SMTP id e9e14a558f8ab-4309bc3e4b3mr21572885ab.12.1760383850537; Mon, 13 Oct 2025 12:30:50 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-42f9036cee5sm53461765ab.32.2025.10.13.12.30.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Oct 2025 12:30:49 -0700 (PDT) Date: Mon, 13 Oct 2025 14:30:48 -0500 From: Nathan Bossart To: Jeff Davis Cc: Tom Lane , Ayush Vatsa , Robert Haas , "David G. Johnston" , PostgreSQL Hackers Subject: Re: Clarification on Role Access Rights to Table Indexes Message-ID: References: <3432170.1758730414@sss.pgh.pa.us> <8af53c6e8992aa706e63aafe60a3bcf100b524d1.camel@j-davis.com> <7b0e2774cdcc8f522ac82f64a8d7266f353a5094.camel@j-davis.com> <31a67adbb10b85ff7cddeafe75b9f6505c902e57.camel@j-davis.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="iujXWOSrXz0NaSpd" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31a67adbb10b85ff7cddeafe75b9f6505c902e57.camel@j-davis.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --iujXWOSrXz0NaSpd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Oct 10, 2025 at 11:31:03AM -0700, Jeff Davis wrote: > On Fri, 2025-10-10 at 11:26 -0500, Nathan Bossart wrote: >> After sleeping on it, I still think this is the right call.  In any >> case, I've spent way too much time on this stuff, so I plan to commit >> the attached soon. > > I'm OK with that. v5-0001 is an improvement over the current situation. Okay, I lied. I spent even more time on these patches and came up with the attached. Here's a summary of what's going on: * 0001 moves the code for stats clearing/setting to use RangeVarGetRelidExtended(). The existing code looks up the relation, locks it, and then checks permissions. There's no guarantee that the relation you looked up didn't concurrently change before locking, and locking before privilege checks is troublesome from a DOS perspective. One downside of using RangeVarGetRelidExtended() is that we can't use AccessShareLock for regular indexes, but I'm not sure that's really a problem since we're already using ShareUpdateExclusiveLock for everything else. The RangeVarGetRelidExtended() callback is similar to the one modified by 0002. This should be back-patched to v18. * 0002 fixes the RangeVarGetRelidExtended() callback for REINDEX INDEX to handle unlikely scenarios involving OID reuse (e.g., lookup returns the same index OID for a different table). I did confirm there was a bug here by concurrently re-creating an index with the same OID for a heap with a different OID (via the pg_upgrade support functions). In previous versions of this patch, I tried to fix this by unconditionally unlocking the heap at the beginning of the callback, but upon further inspection, I noticed that creates deadlock hazards because we might've already locked the index. (We need to lock the heap first.) In v6, I've just added an ERROR for these extremely unlikely scenarios. I've also replaced all early returns in this function with ERRORs (except for the invalid relId case). AFAICT the extra checks are unecessary, and even if they were necessary, I think they break some of the code related to heap locking in subtle ways. Some callbacks do these extra checks, and others do not, and AFAIK there haven't been any reported problems either way. 0002 should be back-patched to v13, but it will look a little different on v16 and newer, i.e., before MAINTAIN was added. * 0003 fixes the privilege checks in pg_prewarm by using a similar approach to amcheck_lock_relation_and_check(). This seems correct to me, but it does add more locking. This should be back-patched to v13. * 0004 is a small patch to teach dblink to use RangeVarGetRelidExtended(). I believe this code predates that function. I don't intend to back-patch this one. -- nathan --iujXWOSrXz0NaSpd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v6-0001-fix-priv-checks-in-stats-code.patch