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 1oaUIe-0000K0-1O for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Sep 2022 03:51:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oaUIc-0003Cx-U7 for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Sep 2022 03:51:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oaUIc-0003Cn-KP for pgsql-hackers@lists.postgresql.org; Tue, 20 Sep 2022 03:51:54 +0000 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oaUIZ-0004YB-Sx for pgsql-hackers@postgresql.org; Tue, 20 Sep 2022 03:51:54 +0000 Received: by mail-pg1-x52f.google.com with SMTP id 78so1250700pgb.13 for ; Mon, 19 Sep 2022 20:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=oTVujxdgCJs9Qf8pL6opr+AqnDbUeJ/5BSA50RYSI4c=; b=F7mKhhqFQPb6tMkRKkGdQYFZFgRgBBvLlQQv3KOKQ3v9Y9rTCImra9q7uwq1duI3QM 7cEpSbRV/5Y2EdAMfmoO6iVQMtZZm2n/IILafI35HUb32Pm6zrkTOiBj/FMIcWdKj2VV GukHVBa20niNs/g5k2/7CWDo1xnxHvVAXDZYMurG+jgLVkNnjxAgZwI2yyscECCJ+jPH CMX1/0qxyQ775yVe9W1KuT/bTDwdRtEimDkNCuMsDQBKm+pZ3ojWowJKMPOdpcz3tIU4 TQyq/H6wPgQPLqwwHBPvRAFwvivV2oLHFxbIza1jCnejlQ3bUNnv77xdwlUpj+RIhWi0 bWqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=oTVujxdgCJs9Qf8pL6opr+AqnDbUeJ/5BSA50RYSI4c=; b=dXFpEmuGV56pKbLomOHI3mxZzDPjPehi/xYRA3uK6kDcnAA6k+k/BRE8m8YZlJXb80 yPZK6USXR3bP+S8qDJETfxyZnkkohSv+8bn3B1m2lajR20UZkAdppv9ubYAE57uMmzUy O2WU/6ydUVh+P/3mU+0yQlRpgROvWqCOig/x/vojKqJzzC8aMmArnGYG663mwbaFeLIs Pm8wYZLsCWLKVNRl2VifTxw30JBzKDuFdVyl0ADFD6wCngxoHzx5r8NWkAZaqFsccT1q LYcsNf05ueCQTLEvFfsk2oTKm9F+56NBEI5ZeYQ79sKzhZi877DQNFf+GyNR5Pc5XXP1 QBVg== X-Gm-Message-State: ACrzQf0dUrm7SBVB+9SOyLz8tk7G2fD27mioj+KQWoOktw3j3AYqZt6O yJAmOPncjUJv+A6WEnyiSgs= X-Google-Smtp-Source: AMsMyM4mudKjD25SUMktG4EA26is/NU3K5sqfMNYgtp14KujSH4zcuR9CMHGHdga2TtgVVxFxOmFYQ== X-Received: by 2002:a62:1a8d:0:b0:544:1309:19f3 with SMTP id a135-20020a621a8d000000b00544130919f3mr21880522pfa.37.1663645909380; Mon, 19 Sep 2022 20:51:49 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id e8-20020aa79808000000b0053b208b55d1sm231478pfl.85.2022.09.19.20.51.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Sep 2022 20:51:48 -0700 (PDT) Date: Mon, 19 Sep 2022 20:51:47 -0700 From: Nathan Bossart To: Robert Haas Cc: Stephen Frost , Bharath Rupireddy , "David G. Johnston" , Kyotaro Horiguchi , "pgsql-hackers@postgresql.org" Subject: Re: predefined role(s) for VACUUM and ANALYZE Message-ID: <20220920035147.GA114383@nathanxps13> References: <20220823234647.GB31055@tamriel.snowman.net> <20220905185630.GA1961927@nathanxps13> <20220906151151.GB26002@tamriel.snowman.net> <20220906155432.GA1963795@nathanxps13> <20220907211343.GE26002@tamriel.snowman.net> <20220907221103.GA2095022@nathanxps13> 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 Thu, Sep 08, 2022 at 09:41:20AM -0400, Robert Haas wrote: > Now on the other hand, I also do think we need more privilege bits. > You're not alone in making the case that this is a problem which needs > to be solved, and the set of other people who are also making that > argument includes me. At the same time, there is certainly a double > standard here. When Andrew and Tom committed > d11e84ea466b4e3855d7bd5142fb68f51c273567 and > a0ffa885e478f5eeacc4e250e35ce25a4740c487 respectively, we used up 2 of > the remaining 4 bits, bits which other people would have liked to have > used up years ago and they were told "no you can't." I don't believe I > would have been willing to commit those patches without doing > something to solve this problem, because I would have been worried > about getting yelled at by Tom. But now here we are with only 2 bits > left instead of 4, and we're telling the next patch author - who is > not Tom - that he's on the hook to solve the problem. > > Well, we do need to solve the problem. But we're not necessarily being > fair about how the work involved gets distributed. It's a heck of a > lot easier for a committer to get something committed to address this > issue than a non-committer, and it's a heck of a lot easier for a > committer to ignore the fact that the problem hasn't been solved and > press ahead anyway, and yet somehow we're trying to dump a problem > that's a decade in the making on Nathan. I'm not exactly sure what to > propose as an alternative, but that doesn't seem quite fair. Are there any concerns with simply expanding AclMode to 64 bits, as done in v5 [0]? [0] https://postgr.es/m/20220908055035.GA2100193%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com