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 1m8lSN-0000aX-7d for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jul 2021 15:26:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m8lSM-0000TU-6w for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jul 2021 15:26:50 +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 1m8lSL-0000TM-Sk for pgsql-hackers@lists.postgresql.org; Wed, 28 Jul 2021 15:26:49 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m8lSJ-00010u-Co for pgsql-hackers@postgresql.org; Wed, 28 Jul 2021 15:26:49 +0000 Received: by mail-pl1-x631.google.com with SMTP id z3so1791733plg.8 for ; Wed, 28 Jul 2021 08:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=Tzvg8AqOzAwN7XQ9s6HP7EVVov8WLA3LjyRH6QK6SCg=; b=d+JXiYh2TfXqTiBx9OhgETk8szmmZY892GbCCrNvaSTWBqYQS0H47tg1Viofu6+Z7l 0gBELBssY/kURnDXyH1tlYzkCm1R/Pln4E6uhOyHnQRgXNhBJl55pVXwqBalcwupjp61 yJ8RV3sSrGvFfTYZ2fi3zibGWW4a+lwmwey2gVUgIBUO/586biE6bMfhom61HP4VKND0 gjBDzP9Ito0gJxLC2rR6VVniw/S4XbGlTJcqzoGbCFZLZDd96NmPv2CShjy+wV4UWUto b+Ne41mjevDNQlRgkm6XJDmmQqqMtOe3KIXLix4KhQuh/iCorELP6Q3SstpTvS6IxaTM pA/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Tzvg8AqOzAwN7XQ9s6HP7EVVov8WLA3LjyRH6QK6SCg=; b=Tv475miTRnGXljLJOiw3UUHKcPFPAm8mrT6WSLunDx5HoMtERl33EjEHpsbOP6Wohu gxz6FCCDQjhbFZM2fKSu4spvSL4phbLvk+Jmo//jhV2kKIzDFI6rJzlGWi6zvV9mY+6e d+27s1BzRymtfdpqZJ8t1fPRjmLbyHbliGjDUEqKs0Vzg16bkW5hoq9wYeIIBFwRQ95C g4joGV79Wc5gv48t9YkS9lDPp6J1ap+PysyiSvIkLB77hrQfbVhcjtHoY4QeX3/BsJ9F MxAubCkbasz0mCbnsA+eQ+40Vq67NSn+D3Q3AxJ2FUvRV1p7hkb0DrK/mM4ahC+2upl5 Uw+Q== X-Gm-Message-State: AOAM533JEO+kn87j4vAX5mLzVd1YzHOCSsOx0Qt7hPP4uhXHrM6c5Ez8 auT5a8SZLc5fUoazZRLaXlaPfg== X-Google-Smtp-Source: ABdhPJyLzcoL0NCwZvToq9Rv5rCah8iD1eqU6sfPTJVHzxuRT/7cJV5H5Qd+VCGcVonjqE2uhucYCg== X-Received: by 2002:a05:6a00:158e:b029:32b:9de5:a198 with SMTP id u14-20020a056a00158eb029032b9de5a198mr336330pfk.3.1627486005360; Wed, 28 Jul 2021 08:26:45 -0700 (PDT) Received: from perhan.alvh.no-ip.org ([201.186.208.143]) by smtp.gmail.com with ESMTPSA id b3sm307492pfi.179.2021.07.28.08.26.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jul 2021 08:26:44 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 503BA2A077D; Wed, 28 Jul 2021 11:26:42 -0400 (-04) Date: Wed, 28 Jul 2021 11:26:42 -0400 From: Alvaro Herrera To: "Drouvot, Bertrand" Cc: Ibrar Ahmed , Amit Khandekar , Andres Freund , fabriziomello@gmail.com, tushar , "[pgdg] Robert Haas" , Rahila Syed , pgsql-hackers Subject: Re: Minimal logical decoding on standbys Message-ID: <202107281526.o74ieuj6sj7z@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Jul-27, Drouvot, Bertrand wrote: > diff --git a/src/backend/utils/cache/lsyscache.c b/src/backend/utils/cache/lsyscache.c > +bool > +get_rel_logical_catalog(Oid relid) > +{ > + bool res; > + Relation rel; > + > + /* assume previously locked */ > + rel = table_open(relid, NoLock); > + res = RelationIsAccessibleInLogicalDecoding(rel); > + table_close(rel, NoLock); > + > + return res; > +} So RelationIsAccessibleInLogicalDecoding() does a cheap check for wal_level which can be done without opening the table; I think this function should be rearranged to avoid doing that when not needed. Also, putting this function in lsyscache.c seems somewhat wrong since it's not merely accessing the system caches ... I think it would be better to move this elsewhere (relcache.c, proto in relcache.h, perhaps call it RelationIdIsAccessibleInLogicalDecoding) and short-circuit for the check that can be done before opening the table. At least the GiST code appears to be able to call this several times per vacuum run, so it makes sense to short-circuit it for the fast case. ... though looking at the GiST code again I wonder if it would be more sensible to just stash the table's Relation pointer somewhere in the context structs instead of opening and closing it time and again. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun)