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 1v8N6C-00H65I-1d for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Oct 2025 18:16:44 +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 1v8N68-007E64-U6 for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Oct 2025 18:16:41 +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 1v8N68-007E5v-Cz for pgsql-hackers@lists.postgresql.org; Mon, 13 Oct 2025 18:16:41 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v8N67-001ZOo-0D for pgsql-hackers@postgresql.org; Mon, 13 Oct 2025 18:16:40 +0000 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-781db5068b8so3587937b3a.0 for ; Mon, 13 Oct 2025 11:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1760379398; x=1760984198; darn=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=16d9cUbHInG1+pl4eoZgejkvWn2SBith4NqtBJn4p04=; b=iKOWrCQLTYcifwQc9GOfcdvYlRewFgE5uuewwv6vRZDeJhVT73sgP00anzDFXpXOcE eUHtEVlJ8yvAgMiBN1txvZduWU1MBde8uS8JMlGPaYXqLuFAoFno3B+APnn48urMd4CR jWgq2TzKQzPVAb2yaiNr+KTsimfWUvFxxAiz2UulZI/+MvMa/jki5dCbVU2SjBXlMomi zNmd/C4SKry9MJ0yOPZocDnDSOPG1OA42PAAWPDwfru3oaKgIWqFE+63E8Zsoin1Myh1 U80hdbmJxlxCf8AJMZCF+7F5RAmur3l+X49n3L53SORMhwDWchhf80xgRiqgiMXhB7E0 8CPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760379398; x=1760984198; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=16d9cUbHInG1+pl4eoZgejkvWn2SBith4NqtBJn4p04=; b=bJXX3PcCYPMD0hZ3e3rFx2yTwrVnvU/JVVkhdy4wACcPugKVs4rQTciC3i1I2JiJdf V9s8XZ0kVQxWZsKzqbIWzw/xcxc98/vT/zYImr/r7IS1OonK4amJ1bPX1l9FHVlaFy1F O/Tq1PXWMUnryYfYVs08z3ZgldBKtNcuzRyiuOls7o5yW9/pI/iq/w+u1DvDI2nIl6H7 vfGn9rK0UoYk+3QM6f9gsw79FAu4FUIJP36leuG/EMrah/Gw1J7PMAg3X3iV6MuwsIzu 4YvaupLKMCjIkJx3SwMRTEgkqJy00KEq7EWXcEdG1lN7DFYdznjIarbiTHeRL1z9Y2Fw 3Qlg== X-Forwarded-Encrypted: i=1; AJvYcCXeQqw4sFFUsJoOymWtUKdrrUABO1UjXTArGpUzlZZBUN2Gnz/c16KtCJBUoFvih9fufQ8jQUXF5x4IhqNL@postgresql.org X-Gm-Message-State: AOJu0Yy/+4B+ZW4FX3HvevEtzDWv/xJEnNMQElptHew1d99iIxOGUy4P OVim82EC0/fZwwQRphTFZq24kmFjcC7PHkGDCnztugQrrsdlDI+hNWCGcyfGGbiegQ== X-Gm-Gg: ASbGnctVZBbwfF918QZtUiypm8ltrJPxCDSdn9XdjrRFnYTfYpllk8mE0rfHII8Fp9I fXC/zeFcuDJWM5NGrCXQCwP9xaUzxTFHKp+wcogLYUD8E8B+OBD3MwZx0Simd8gcraAivXFk6Id AU0/YkilPzj/TSSOQtJD9lr+P2t9aiHIdWlvMZ4f0D6qohspNyFJvLNP5h3pBdz4PIUkh+0hUbr qrIgRnwdNV0S44eyK4kunVG60HMS9+RG2R9p8cN08xSph12crvY/C7Bz+2IBV0GtND6SVRIQn2x mXx080aGHSEY6UiKvJn3+sc+2I9eBT8HBypIIG/9qOac/AO/mcJim4rpsFxpjQ19a7d9oDH9G34 RkcKAZd1yVjBYQMckzycJjEvVjzFl3QimCuUGGBb/ddUIkCidlWcKk3+Rw+1w2iuvCs33bYBvCA == X-Google-Smtp-Source: AGHT+IE3gksbl7kKgWfwNfxGB7M+1TGnY6WFMHeOSZ+pYLc6YZjYyo+CJl6RBL/8eJJrBZ9560Fw4A== X-Received: by 2002:a05:6a00:1883:b0:77f:4a83:8f9 with SMTP id d2e1a72fcca58-793859f34c4mr26541371b3a.2.1760379397759; Mon, 13 Oct 2025 11:16:37 -0700 (PDT) Received: from jeff-ws-bridge.lan (c-24-7-19-3.hsd1.ca.comcast.net. [24.7.19.3]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7992b0606f0sm12655195b3a.15.2025.10.13.11.16.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Oct 2025 11:16:37 -0700 (PDT) Message-ID: <67e077fcfe474ce7c56d36492d89c150768271e1.camel@j-davis.com> Subject: Re: Clarification on Role Access Rights to Table Indexes From: Jeff Davis To: Tom Lane , Nathan Bossart Cc: Ayush Vatsa , Robert Haas , "David G. Johnston" , PostgreSQL Hackers Date: Mon, 13 Oct 2025 11:16:36 -0700 In-Reply-To: <3432170.1758730414@sss.pgh.pa.us> References: <149429.1741472260@sss.pgh.pa.us> <279947.1741535285@sss.pgh.pa.us> <3432170.1758730414@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.3-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2025-09-24 at 12:13 -0400, Tom Lane wrote: > Don't we do that intentionally, to make sure someone can't cause DOS > on a table they have no privileges on? Is this only a problem for strong locks (ShareLock or greater)? Strong locks are a problem when you have a pattern like a long running query that holds an AccessShareLock, and then an unprivileged user requests an AccessExclusiveLock, forcing other queries to queue up behind it, and the queue doesn't clear until the long running query finishes. But weaker locks don't seem to have that problem, right? Regards, Jeff Davis