Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHBxI-0004HV-Vy for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Jul 2022 22:26:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oHBxH-0006bo-RX for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Jul 2022 22:26:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHBxH-0006b7-GO for pgsql-hackers@lists.postgresql.org; Thu, 28 Jul 2022 22:26:07 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oHBxF-0008NL-5D for pgsql-hackers@postgresql.org; Thu, 28 Jul 2022 22:26:06 +0000 Received: by mail-pl1-x62e.google.com with SMTP id b22so2976936plz.9 for ; Thu, 28 Jul 2022 15:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UFpxqvpGuUpd8ZQhFzMJQ+s/ohc7ppEdqpJxRyeLJUU=; b=HY0nbtNGQL7cfuv+rgBavqDiTGxO5sVPx+f88///607dnR9XcwMPZS/N0aItlKNYOQ xQoSa4G1fGekx/H+yfYX7cHGguFtQB5TeQX/Qb9A3Ys1706icD3v9xiNTn3hTAWgCWG4 lfKyj+HWOtC71wIPmwa5Oj9GIoiQTL7Q9EgQ3OcdvSPLHuKLMthGM7l9+OAo7XPD0BpA RfDoSh8nqRVIL7qzNP//jOOrUKevxjofwO3/xnW6I7Ucu0j0JJUeMl1hSjiUt15CglpD v6USxB7vLo3hmjL5E9qozkn/JmlbswvkP2R1nNp67XO67z87mclkgWbvtcsxcd2NK3DT buuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UFpxqvpGuUpd8ZQhFzMJQ+s/ohc7ppEdqpJxRyeLJUU=; b=aJjcPDfcyu9r/tGAH0un7KcFUoVhydnG2axEXAMUtLw91s7sRIY3XnZihEUoSlh03P 6b6vajA6tjJZMw28gL0xDwlMN3bYGW5bcPfXUTD5yuJsxzTuGIJRTXyNpja+Z3zlNB3Q cU7hUd6hTf3k16lvsDnS02M+Bz+kRGG7KXrnkLVD/y0+5mWg4Gq2KN9GSUVOwnbphVm1 RF4HP1jbwT7TEWZj92YjBJBaWxujRv3wBIs77Va7C4zx/WrfNoH3MsY3VFkZY6s+zcan Bqc77COyJGEhY7BKwMR1EEQEP6OQSHsYi9/1LcWfJdCqG8pdTZBXHX1kQ/5w49oZFiXg DtEg== X-Gm-Message-State: ACgBeo01Z2J6ANK/Eod/t6AdkK/FGmTrPAwJF6KKWMVzGllZRr4Dbgqs Fr+Jx33nturDpmjJ77Ss4nc= X-Google-Smtp-Source: AA6agR4kRX8tSGjshZEpBVEj0oJXZ5TsGicq6JEczbDW/uFXGbFoOkMvTRbPfWUeB/4iDNRZRI30Mg== X-Received: by 2002:a17:903:32d0:b0:16d:7601:6bbc with SMTP id i16-20020a17090332d000b0016d76016bbcmr1003634plr.16.1659047164082; Thu, 28 Jul 2022 15:26:04 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id hi7-20020a17090b30c700b001f2fa09786asm1608591pjb.19.2022.07.28.15.26.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 15:26:03 -0700 (PDT) Date: Thu, 28 Jul 2022 15:26:02 -0700 From: Nathan Bossart To: Robert Haas Cc: "David G. Johnston" , Kyotaro Horiguchi , Bharath Rupireddy , "pgsql-hackers@postgresql.org" Subject: Re: predefined role(s) for VACUUM and ANALYZE Message-ID: <20220728222602.GA410772@nathanxps13> References: <20220722203735.GB3996698@nathanxps13> <20220725164049.GA4091959@nathanxps13> <20220726.104712.912995710251150228.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jul 26, 2022 at 01:54:38PM -0400, Robert Haas wrote: > I think we're down to 0 remaining now, so it'd be hard to justify > consuming 2 of 0 remaining bits. AFAICT there are 2 remaining. N_ACL_RIGHTS is only 14. > However, I maintain that the solution > to this is either (1) change the aclitem representation to get another > 32 bits or (2) invent a different system for less-commonly used > permission bits. Checking permissions for SELECT or UPDATE has to be > really fast, because most queries will need to do that sort of thing. > If we represented VACUUM or ANALYZE in some other way in the catalogs > that was more scalable but less efficient, it wouldn't be a big deal > (although there's the issue of code duplication to consider). Perhaps we could add something like a relacl_ext column to affected catalogs with many more than 32 privilege bits. However, if we actually do have 2 bits remaining, we wouldn't need to do that work now unless someone else uses them first. That being said, it's certainly worth thinking about the future of this stuff. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com