From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
Subject: Re: Minimal logical decoding on standbys
To: Alvaro Herrera <alvherre@2ndquadrant.com>
CC: Ibrar Ahmed <ibrar.ahmad@gmail.com>, Amit Khandekar
	<amitdkhan.pg@gmail.com>, Andres Freund <andres@anarazel.de>,
	<fabriziomello@gmail.com>, tushar <tushar.ahuja@enterprisedb.com>, "[pgdg]
 Robert Haas" <robertmhaas@gmail.com>, Rahila Syed
	<rahila.syed@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
References: <202107281526.o74ieuj6sj7z@alvherre.pgsql>
 <ae1f2199-65e7-a431-d79e-c32b9379aa6e@amazon.com>
Message-ID: <b8cfc33a-36f0-a247-1c61-13500ef5ab0a@amazon.com>
Date: Thu, 9 Sep 2021 09:17:27 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <ae1f2199-65e7-a431-d79e-c32b9379aa6e@amazon.com>
Content-Type: multipart/alternative;
	boundary="------------26F3DC7BFE89E934791EB596"
Content-Language: en-US
Archived-At: 
 <https://www.postgresql.org/message-id/b8cfc33a-36f0-a247-1c61-13500ef5ab0a%40amazon.com>
Precedence: bulk

--------------26F3DC7BFE89E934791EB596
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alvaro,

On 8/2/21 4:56 PM, Drouvot, Bertrand wrote:
> Hi Alvaro,
>
> On 7/28/21 5:26 PM, Alvaro Herrera wrote:
>> 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.
>
> Thanks for looking at it.
>
>
>> 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.

So you have in mind to check for XLogLogicalInfoActive() first, and if 
true, then open the relation and call
RelationIsAccessibleInLogicalDecoding()?

If so, then what about also creating a new 
RelationIsAccessibleWhileLogicalWalLevel() or something like this doing 
the same as RelationIsAccessibleInLogicalDecoding() but without the 
XLogLogicalInfoActive() check?

>> 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 

Do you have a "good place" in mind?

Thanks

Bertrand


--------------26F3DC7BFE89E934791EB596
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Alvaro,<br>
    </p>
    <div class="moz-cite-prefix">On 8/2/21 4:56 PM, Drouvot, Bertrand
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:ae1f2199-65e7-a431-d79e-c32b9379aa6e@amazon.com">Hi
      Alvaro, <br>
      <br>
      On 7/28/21 5:26 PM, Alvaro Herrera wrote: <br>
      <blockquote type="cite">On 2021-Jul-27, Drouvot, Bertrand wrote: <br>
        <br>
        <blockquote type="cite">diff --git
          a/src/backend/utils/cache/lsyscache.c
          b/src/backend/utils/cache/lsyscache.c <br>
          +bool <br>
          +get_rel_logical_catalog(Oid relid) <br>
          +{ <br>
          +     bool    res; <br>
          +     Relation rel; <br>
          + <br>
          +     /* assume previously locked */ <br>
          +     rel = table_open(relid, NoLock); <br>
          +     res = RelationIsAccessibleInLogicalDecoding(rel); <br>
          +     table_close(rel, NoLock); <br>
          + <br>
          +     return res; <br>
          +} <br>
        </blockquote>
        So RelationIsAccessibleInLogicalDecoding() does a cheap check
        for <br>
        wal_level which can be done without opening the table; I think
        this <br>
        function should be rearranged to avoid doing that when not
        needed. <br>
      </blockquote>
      <br>
      Thanks for looking at it. <br>
      <br>
      <br>
      <blockquote type="cite">Also, putting this function in lsyscache.c
        seems somewhat wrong since <br>
        it's not merely accessing the system caches ... <br>
        <br>
        I think it would be better to move this elsewhere (relcache.c,
        proto in <br>
        relcache.h, perhaps call it
        RelationIdIsAccessibleInLogicalDecoding) and <br>
        short-circuit for the check that can be done before opening the
        table. <br>
      </blockquote>
    </blockquote>
    <p>So you have in mind to check for <span class="preprocessor">XLogLogicalInfoActive()
        first, and if true, then open the relation and call </span><br>
      <span class="preprocessor">RelationIsAccessibleInLogicalDecoding()?</span></p>
    <p><span class="preprocessor">If so, then what about also creating a
        new </span><span class="preprocessor"><span
          class="preprocessor">RelationIsAccessibleWhileLogicalWalLevel()
          or something like this doing the same as </span></span><span
        class="preprocessor">RelationIsAccessibleInLogicalDecoding() but
        without the </span><span class="preprocessor">XLogLogicalInfoActive()
        check?</span></p>
    <blockquote type="cite"
      cite="mid:ae1f2199-65e7-a431-d79e-c32b9379aa6e@amazon.com">
      <blockquote type="cite">At least the GiST code appears to be able
        to call this several times per <br>
        vacuum run, so it makes sense to short-circuit it for the fast
        case. <br>
        <br>
        ... though looking at the GiST code again I wonder if it would
        be more <br>
        sensible to just stash the table's Relation pointer somewhere in
        the <br>
        context structs </blockquote>
    </blockquote>
    <p>Do you have a "good place" in mind? <br>
    </p>
    <p>Thanks</p>
    <p>Bertrand<br>
    </p>
  </body>
</html>

--------------26F3DC7BFE89E934791EB596--