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 1oami8-0001zL-FE for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Sep 2022 23:31:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oami6-0003Fd-7N for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Sep 2022 23:31:26 +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 1oami5-0003FR-SP for pgsql-hackers@lists.postgresql.org; Tue, 20 Sep 2022 23:31:25 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oami1-00062U-Im for pgsql-hackers@postgresql.org; Tue, 20 Sep 2022 23:31:25 +0000 Received: by mail-pl1-x62c.google.com with SMTP id f23so3941507plr.6 for ; Tue, 20 Sep 2022 16:31:20 -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=C6VpVngLvec64pFGfvmuV4MHHmXBPJRX2ZR7LgP+gJk=; b=IfNcCSGjq3HoVlkKzTikMdXIKNVdpQgo8OWdAB3KncV08+7t8BwIQNmX0teTpCwILQ YXYz05mGqGaiy9Byg24oRI6ayw7nkTRgd6rO+lNXeUKR7zsfQxKXPsfdtcSY0RuCDxCS hiWgVf6SdCORHaX3R6C7gnTouGbeM4HBgI6yOxvKdAkQjtbcdyquhphhUs0124yUDaIx FHcWhC46U/ITKF2pwoT0Rjlqua+LhTNC0ORlIM8v+TKLz/1gPWQ26BakXMqmW7s+uMTL +AM77jn5oa+2PlP5SFPq8C8S7gCOw4LBFIilm5SyiBYQKnlFfVEhk5ulFVWkUUmPhpyR wPjw== 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=C6VpVngLvec64pFGfvmuV4MHHmXBPJRX2ZR7LgP+gJk=; b=KbGW2RZXu/teJ5EDHYyM9ZidAUpclo7LprC+GkTzMVjlq5fmO29z2SLSKmDDxzHmwn bpOn+4pAHK3ZUsTH7coJD5K5YEHvryzyBhnACu9qwQhYfI/xijYIU8RkQ01HeZ19m3Pk Z8LlYKwqWAxuZBpVQocyW9wgl6FX7aHcu8fuwPfywo9BzMpIctyvJHFxDouYzel6TRNW 4AfsO4/X4BRKtRtwk8wIp70+4KYhD4MnAWGFr6qYJoGeIqN1kXMcHB73C1X583cPaiyE C9ae3eUE21pLSkBrYJ1f1lZd5DfigIHFDjS3ZofX0FT5IOqikXts88CaHdB7a6sZSENz eEJg== X-Gm-Message-State: ACrzQf1Gyq7qpT4YzVmgeqr5uZQVIIoOjrRNhORXVopYgza7unBIhSis XfUow1/TYkcYiQu7ReX4MuM8vqhqcRQ= X-Google-Smtp-Source: AMsMyM6mYj9anTQyUMWChWs0OM2XZFVD/UOVDhw6IdTrRL5efPEo2or90vNdWIQ0NfnvklTDuLjDXA== X-Received: by 2002:a17:903:120d:b0:178:a6ca:b974 with SMTP id l13-20020a170903120d00b00178a6cab974mr1954441plh.8.1663716679366; Tue, 20 Sep 2022 16:31:19 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id m14-20020a17090a5a4e00b00203a671a4c2sm470936pji.26.2022.09.20.16.31.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 16:31:18 -0700 (PDT) Date: Tue, 20 Sep 2022 16:31:17 -0700 From: Nathan Bossart To: Michael Paquier Cc: Robert Haas , Stephen Frost , Bharath Rupireddy , "David G. Johnston" , Kyotaro Horiguchi , "pgsql-hackers@postgresql.org" Subject: Re: predefined role(s) for VACUUM and ANALYZE Message-ID: <20220920233117.GA378596@nathanxps13> References: <20220906151151.GB26002@tamriel.snowman.net> <20220906155432.GA1963795@nathanxps13> <20220907211343.GE26002@tamriel.snowman.net> <20220907221103.GA2095022@nathanxps13> <20220920035147.GA114383@nathanxps13> <20220920180533.GA205278@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220920180533.GA205278@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote: > On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote: >> Any impact for the column sizes of the catalogs holding ACL >> information? Just asking while browsing the patch set. > > Since each aclitem requires 16 bytes instead of 12, I assume so. However, > in my testing, I hit a "row is too big" error with the same number of > aclitems in a pg_class row before and after the change. I might be missing > something in my patch, or maybe I am misunderstanding how arrays of > aclitems are stored on disk. Ah, it looks like relacl is compressed. The column is marked "extended," but pg_class doesn't appear to have a TOAST table, so presumably no out-of-line storage can be used. I found a couple of threads about this [0] [1] [2]. [0] https://postgr.es/m/17245.964897719%40sss.pgh.pa.us [1] https://postgr.es/m/200309040531.h845ViP05881%40candle.pha.pa.us [2] https://postgr.es/m/29061.1265327626%40sss.pgh.pa.us -- Nathan Bossart Amazon Web Services: https://aws.amazon.com