Re: BUG #19647: Difference in pg_basebackup behaviour between PostgreSQL <= 16 and >= 17 with pgactive extension

From: Edwin Polkerman <edwin(dot)polkerman(at)splendiddata(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19647: Difference in pg_basebackup behaviour between PostgreSQL <= 16 and >= 17 with pgactive extension
Date: 2026-09-03 11:55:24
Message-ID: cd4f60fe-c8e7-4c15-ae98-6056242d0081@splendiddata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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(dot)polkerman(at)splendiddata(dot)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/>*

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Rachitskiy 2026-09-03 15:29:28 Re: BUG #19650: to_date()/to_timestamp() silently truncate 4+-digit day-of-year input to the first three digits
Previous Message Kirill Reshke 2026-09-03 06:48:10 Re: BUG #19628: Uninterruptible vacuum during hash index processing

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-09-03 12:04:00 Re: pgstat: Flush some statistics within running transactions, take 2
Previous Message Bertrand Drouvot 2026-09-03 11:54:22 Re: Offline data checksum changes can cause incorrect checksum state on standbys