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 1oeNrA-0005Fk-LF for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Sep 2022 21:47:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oeNr9-0001jn-8W for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Sep 2022 21:47:39 +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 1oeNr8-0001jd-TP for pgsql-hackers@lists.postgresql.org; Fri, 30 Sep 2022 21:47:38 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oeNr2-0000Zd-2G for pgsql-hackers@postgresql.org; Fri, 30 Sep 2022 21:47:37 +0000 Received: by mail-pl1-x633.google.com with SMTP id w10so5018416pll.11 for ; Fri, 30 Sep 2022 14:47:31 -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=O7Fw0q0nt/5QzW43SHIV9GdsZj4XRkhgraf25Jan97I=; b=c3yfkV/1KyLV0DNcOcEPzH8bMBvAJxxj0e0yUfwKNRGqkDbwPDIMzVbIn9q1eW1tjn w/LhNLd8rEtDEpC0pb0zR0hyTiEtjlhostQbDdvcT/ZPbBECp2naaiuAvZI6T0d5gFUO Gm8ho9jafZtKr31LSH4J5t1a0M1Cmb01m5sA2TrfDdMLvZd5DFYfpv4+0rgMUjO/+3i0 NctIdjzM+9IkleIZd9/3SKPvx+rlHYeQcGqSICipspyddUFzLR6uCEWvQiJNqMLf/yPu 5nVC+/1cph5FDr2Xajhab6SfUyD/7xWYHqajc4JyHXloIJFblbX6ntulkpbgIWGe9WH9 YJZg== 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=O7Fw0q0nt/5QzW43SHIV9GdsZj4XRkhgraf25Jan97I=; b=7rafre7Lw2BLvHBRbcUj+iMtVgOpLiyyF0E/eXJTBXuzt4/ikauFV9IMnH4CMT+fnV CVas/qYh7Z74ny4HWv+OGM0Om2J0/BVRhB2KaNV3oBB5cACZaEKEMv8DIDWceK68GYwI hHZ9pE++Dm2P7O0QIHQq+hDBfJoUoFw0sJ+5Y1mu6g7KTGruGRjyVCqCG0UfVysMGLVC qb/vt6mgeIH0elaLZ4TQoMXfDJPpfG1x9xpddD3tWylJWRMF60cv3pqIk9JIVaBjqklM hCEQtyUGV2RU8j/kQpSgEEAl8tyxuSz3SDmizGktX18j2EiBby5dz+vV+vBNbcTCZcbq crvQ== X-Gm-Message-State: ACrzQf2ZQXDYqo30zVnkHdcQGFOBky/Yl+Oe6yi9RqGw4O1o9vf0qekH pVyisouM3EGuY5mzvvrIpZg= X-Google-Smtp-Source: AMsMyM6ueXy/ZwFLDHNa83sHoOm0ETq5Yb0RmYTZ06ZYlHTDaUbNxIRnTeEgNIjuvjYYppFiursxRw== X-Received: by 2002:a17:903:40c5:b0:17c:830f:1f6e with SMTP id t5-20020a17090340c500b0017c830f1f6emr4701949pld.144.1664574450764; Fri, 30 Sep 2022 14:47:30 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id v9-20020a1709029a0900b00179c9219195sm2373268plp.16.2022.09.30.14.47.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 14:47:29 -0700 (PDT) Date: Fri, 30 Sep 2022 14:47:28 -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: <20220930214728.GA177925@nathanxps13> References: <20220920180533.GA205278@nathanxps13> <20220920233117.GA378596@nathanxps13> <20220920235010.GB378596@nathanxps13> <20220921043126.GA382738@nathanxps13> <20220928185034.GA1397229@nathanxps13> <20220928201222.GA1400058@nathanxps13> <20220930192350.GA171832@nathanxps13> <678838.1664568924@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <678838.1664568924@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 04:15:24PM -0400, Tom Lane wrote: > In view of the recent mess around bigint relfilenodes, it seems to me > that we shouldn't move forward with widening AclMode unless somebody > runs down which structs will get wider (or more aligned) and how much > that'll cost us. Maybe it's not a problem, but it could do with an > explicit look at the point. The main one I see is AclItem, which increases from 12 bytes to 16 bytes. AFAICT all of the catalogs that store aclitem arrays have the aclitem[] column marked extended, so they are compressed or moved out-of-line as needed, too. The only other structs I've spotted that make use of AclMode are InternalGrant and InternalDefaultACL. I haven't identified anything that leads me to believe there are alignment problems or anything else comparable to the issues listed in the relfilenode thread [0], but I could be missing something. Did you have something else in mind you think ought to be checked? I'm not sure my brief analysis here suffices. [0] https://postgr.es/m/CA%2BTgmoaa9Yc9O-FP4vS_xTKf8Wgy8TzHpjnjN56_ShKE%3DjrP-Q%40mail.gmail.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com