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 1oeOZ9-0000of-1B for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Sep 2022 22:33:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oeOZ7-0004P2-Rf for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Sep 2022 22:33:05 +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 1oeOZ7-0004Ot-GF for pgsql-hackers@lists.postgresql.org; Fri, 30 Sep 2022 22:33:05 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oeOZ4-00049m-Jy for pgsql-hackers@postgresql.org; Fri, 30 Sep 2022 22:33:04 +0000 Received: by mail-pj1-x102f.google.com with SMTP id u59-20020a17090a51c100b00205d3c44162so10370053pjh.2 for ; Fri, 30 Sep 2022 15:33:02 -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=kSj4ZwyKdlpigPpeVTJcuiENY9d7k9SZBqfdZTLvcz4=; b=nsfsQrTiqPE6+Qu94de4MHmhwUFiWRyVRVA8MXY4WIttnNSVx6rXCQf0rJnWU0gMfx X8QHWB4voivT6IhVr71tahilVaGvKya/p4v6LUfKDyUGBeZq8wMh2aitXLk+39kkimVG Bd633XJ6972wmKQqhqm2+BilsYlyzTiUa+J7ACZ8+l1EPKCKvTwEK36o1yCZUJEHCVjK aEBh6EoN5pEFGbnb6R07LuWdMtMHK3aipqQyaAe+M/etZPcQcdeWkIeq76n186CgY88T ISMegeJtM+NyKOUW52h0/dHEUtGmeT170Woy5GllW/yzTps/RlVs2d0LUnde2PktNp77 vwfw== 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=kSj4ZwyKdlpigPpeVTJcuiENY9d7k9SZBqfdZTLvcz4=; b=GIiy2Q3aWqR9u7rWG0LBIaP3lnrrkvLGuinUdXvuWkQMHgPXy5crh1Z/ctxrINPKGw YJdwqPcVauAnbcG9RtBf6gUgg0UFwhtPaMQoJh7irvnjTZZsTO0NslbBrfCJDuTtpHs3 k2KvjAPlX1ujouKv4w3fviaGCaRKys/11r14e4p3JtWXaZAR+U+RoZEtprlouiXzATRD vS6QyuXuHLo7BYVIKqrxXJSeXrcWuKrZMklKEXRBViwNlgWIBhMuWVw4azc/mdoNrvHa 3TYwWiBXoUwMq2pkZ3HWwIp2Ekhjl8z4Fx2PFGKyH41ptkqYGUe8Iew2YChwKAC95Cdv gYeQ== X-Gm-Message-State: ACrzQf0IVp3S5CZvsU6tmkQXsOC8tuAJhQA+YvqZHenPt5m3kL0CRR8Y 3O9vUvXV5z790cHbaBNN9RE= X-Google-Smtp-Source: AMsMyM7v0x9jGg8Oo1Jm6KSEfc4GRywMKLtXAGlDAG/f1GA1aN/CrMBBKymjNf+q3OpZ3c4dg/Kftw== X-Received: by 2002:a17:903:248:b0:172:7520:db07 with SMTP id j8-20020a170903024800b001727520db07mr10982985plh.76.1664577180273; Fri, 30 Sep 2022 15:33:00 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id p6-20020a170902780600b0015e8d4eb26esm2393568pll.184.2022.09.30.15.32.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 15:32:59 -0700 (PDT) Date: Fri, 30 Sep 2022 15:32:57 -0700 From: Nathan Bossart To: Tom Lane Cc: Stephen Frost , Bharath Rupireddy , "David G. Johnston" , Kyotaro Horiguchi , Michael Paquier , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: predefined role(s) for VACUUM and ANALYZE Message-ID: <20220930223257.GA190214@nathanxps13> References: <20220920235010.GB378596@nathanxps13> <20220921043126.GA382738@nathanxps13> <20220928185034.GA1397229@nathanxps13> <20220928201222.GA1400058@nathanxps13> <20220930192350.GA171832@nathanxps13> <678838.1664568924@sss.pgh.pa.us> <20220930214728.GA177925@nathanxps13> <742523.1664575253@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <742523.1664575253@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> The main one I see is AclItem, which increases from 12 bytes to 16 bytes. > > ... and now requires double alignment ... did you fix its typalign? Nope, I missed that, thanks for pointing it out. Should we move ai_privs to the beginning of the struct, too? The only other similar example I see is TimeTzADT, but that only consists of an int64 and an int32, while AclItem starts with 2 uint32s. While it might not be strictly necessary, it seems like there is a small chance it could become necessary in the future. > We could conceivably dodge the alignment increase by splitting the 64-bit > field into two 32-bit fields, one for base privileges and one for grant > options. That'd be rather invasive, so unless it leads to pleasant > improvements in readability (which it might, perhaps) I wouldn't advocate > for it. Yeah, the invasiveness is the main reason I haven't tried this yet, but it does seem like it'd improve readability. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com