Content-Type: multipart/alternative;
 boundary="------------AS4z3OigMBPaS2lCM4Wt90ya"
Message-ID: <cd4f60fe-c8e7-4c15-ae98-6056242d0081@splendiddata.com>
Date: Thu, 3 Sep 2026 13:55:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19647: Difference in pg_basebackup behaviour between
 PostgreSQL <= 16 and >= 17 with pgactive extension
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: pgsql-bugs@lists.postgresql.org
References: <19647-d18354ebe2134a6d@postgresql.org>
 <CAOYmi+=QyQHvH2Ehqb+Je3nvv-+Qg6Xp8fG+cNs-KwAoHvNyBA@mail.gmail.com>
 <b39d0277-de91-4fa1-b912-e3c8ee38ccf1@splendiddata.com>
 <CAOYmi+myfnx3eC-jpTxGgtTPL5eMitu_nV9PkyqDS8W4puoNcw@mail.gmail.com>
Content-Language: en-US
From: Edwin Polkerman <edwin.polkerman@splendiddata.com>
Organization: Splendid Data Nederland B.V.
In-Reply-To: 
 <CAOYmi+myfnx3eC-jpTxGgtTPL5eMitu_nV9PkyqDS8W4puoNcw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/cd4f60fe-c8e7-4c15-ae98-6056242d0081%40splendiddata.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------AS4z3OigMBPaS2lCM4Wt90ya
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jacob,

I think I understand it...

Keeps me only wondering why the behaviour change in pg_basebackup is not 
implemented for PG14 to 16 as well.

Now you can have a situation in which

a) pg_basebackup and pg_checksums 'complain' consistent about checksum 
issues in data location

b) pg_basebackup ignores checksum issues on files not owned/managed by 
postgresql but pg_checksums will still complain about them in the data 
location.

Or is that what you mean for 'b)' below, an enhancement request for 
pg_checksums to treat checksums the way pg_basebackup does (pg >= 17)?

> It's possible that today's pg_checksums behavior was an oversight,
> because pg_checksums.c says
>
>      /*
>       * List of files excluded from checksum validation.
>       *
>       * Note: this list should be kept in sync with what basebackup.c
> includes.
>       */
>
> and it sure seems like that list is no longer "in sync". But
> personally, I don't think that's a backportable change, rather than an
> enhancement request for future versions.

I will file a bug report for this issue in github for the third-party 
extension pgactive. Please let me know if you want me to report an 
enhancement request or thet you take care about that

Kind regards,

Edwin


On 9/2/26 23:19, Jacob Champion wrote:
> Hi Edwin,
>
> On Wed, Sep 2, 2026 at 1:43 PM Edwin Polkerman
> <edwin.polkerman@splendiddata.com> wrote:
>> Yes, the 18.6 and 17.11 global/ directory contains this file as well.
>> [...]
>> Because of the difference in behaviour of pg_basebackup what dazzled me, it made me decide to create the issue in the pgql-bugs mailing list. Please let me know if it is not PostgreSQL related and if it should be created in github at AWS/pgactive
> It looks like the behavior change in pg_basebackup is by design [1], as of PG17.
>
> I think that's separate from the general question of "do our checksum
> tools handle arbitrary third-party files in arbitrary places", and I
> think the answer to that is still "no". There was briefly some
> discussion on allowing that, IIRC -- but as far as I know, it hasn't
> actually been established as a supported feature? (It is clearly not
> supported for PG16 and before, so I think a trip to the extension's
> GitHub Issues is probably in your future either way.)
>
> It's possible that today's pg_checksums behavior was an oversight,
> because pg_checksums.c says
>
>      /*
>       * List of files excluded from checksum validation.
>       *
>       * Note: this list should be kept in sync with what basebackup.c
> includes.
>       */
>
> and it sure seems like that list is no longer "in sync". But
> personally, I don't think that's a backportable change, rather than an
> enhancement request for future versions.
>
> Thanks,
> --Jacob
>
> [1]https://postgr.es/c/025584a16
-- 

Splendid Data Nederland B.V.
Binnenhof 62A
1412 LC NAARDEN
+31 85 773 19 99
+31 6 5118 8231

*Follow us on LinkedIn <https://www.linkedin.com/company/3327997/admin/>*
--------------AS4z3OigMBPaS2lCM4Wt90ya
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Liberation Sans">Hi Jacob,</font></p>
    <p><font face="Liberation Sans">I think I understand it...</font></p>
    <p><font face="Liberation Sans">Keeps me only wondering why the
        behaviour change in pg_basebackup is not implemented for PG14 to
        16 as well.</font></p>
    <p><font face="Liberation Sans">Now you can have a situation in
        which</font></p>
    <p><font face="Liberation Sans">a) pg_basebackup and pg_checksums
        'complain' consistent about checksum issues in data location</font></p>
    <p><font face="Liberation Sans">b) pg_basebackup ignores checksum
        issues on files not owned/managed by postgresql but pg_checksums
        will still complain about them in the data location.</font></p>
    <p><font face="Liberation Sans">Or is that what you mean for 'b)'
        below, an enhancement request for pg_checksums to treat
        checksums the way pg_basebackup does (pg &gt;= 17)?</font></p>
    <p><font face="Liberation Sans">
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">It's possible that today's pg_checksums behavior was an oversight,
because pg_checksums.c says

    /*
     * List of files excluded from checksum validation.
     *
     * Note: this list should be kept in sync with what basebackup.c
includes.
     */

and it sure seems like that list is no longer "in sync". But
personally, I don't think that's a backportable change, rather than an
enhancement request for future versions.
</pre>
        </blockquote>
        <br>
      </font></p>
    <p><font face="Liberation Sans">I will file a bug report for this
        issue in github for the third-party extension pgactive. Please
        let me know if you want me to report an enhancement request or
        thet you take care about that</font></p>
    <p><font face="Liberation Sans">Kind regards,</font></p>
    <p><font face="Liberation Sans">Edwin</font></p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 9/2/26 23:19, Jacob Champion wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOYmi+myfnx3eC-jpTxGgtTPL5eMitu_nV9PkyqDS8W4puoNcw@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">Hi Edwin,

On Wed, Sep 2, 2026 at 1:43 PM Edwin Polkerman
<a class="moz-txt-link-rfc2396E" href="mailto:edwin.polkerman@splendiddata.com">&lt;edwin.polkerman@splendiddata.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Yes, the 18.6 and 17.11 global/ directory contains this file as well.
[...]
Because of the difference in behaviour of pg_basebackup what dazzled me, it made me decide to create the issue in the pgql-bugs mailing list. Please let me know if it is not PostgreSQL related and if it should be created in github at AWS/pgactive
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
It looks like the behavior change in pg_basebackup is by design [1], as of PG17.

I think that's separate from the general question of "do our checksum
tools handle arbitrary third-party files in arbitrary places", and I
think the answer to that is still "no". There was briefly some
discussion on allowing that, IIRC -- but as far as I know, it hasn't
actually been established as a supported feature? (It is clearly not
supported for PG16 and before, so I think a trip to the extension's
GitHub Issues is probably in your future either way.)

It's possible that today's pg_checksums behavior was an oversight,
because pg_checksums.c says

    /*
     * List of files excluded from checksum validation.
     *
     * Note: this list should be kept in sync with what basebackup.c
includes.
     */

and it sure seems like that list is no longer "in sync". But
personally, I don't think that's a backportable change, rather than an
enhancement request for future versions.

Thanks,
--Jacob

[1] <a class="moz-txt-link-freetext" href="https://postgr.es/c/025584a16">https://postgr.es/c/025584a16</a>
</pre>
    </blockquote>
    <div class="moz-signature">-- <br>
      <br>
      <!-- <div style="color:rgb(0,0,0);font-family:Calibri;font-size:medium"><img src="/home/epolkerman/Nextcloud/Edwin/Documents/SplendidData_logo/logotype-splendiddata-v2.0-01.png" width="200" height="56"></div> -->
      <div
        style="color:rgb(0,0,0);font-family:Liberation;font-size:medium">
        <div style="color:rgb(32,33,36)"><font face="Liberation Sans"
            size="2" color="#274e13">Splendid Data Nederland B.V.</font></div>
        <div style="color:rgb(32,33,36)"><font face="Liberation Sans"
            size="2" color="#274e13">Binnenhof 62A</font></div>
        <div style="color:rgb(32,33,36)"><font face="Liberation Sans"
            size="2" color="#274e13">1412 LC NAARDEN</font></div>
        <div style="color:rgb(32,33,36)"><font face="Liberation Sans"
            size="2" color="#274e13">+31 85 773 19 99</font></div>
        <div><font face="Liberation Sans" size="2" color="#7f7f7f">+31 6
            5118 8231</font></div>
        <div><font face="Liberation Sans" size="2" color="#7f7f7f"><br>
          </font></div>
        <div><font face="Liberation Sans" size="2" color="#7f7f7f"><b>Follow
              us on <a
                href="https://www.linkedin.com/company/3327997/admin/"
                target="_blank">LinkedIn</a></b></font></div>
      </div>
    </div>
  </body>
</html>

--------------AS4z3OigMBPaS2lCM4Wt90ya--