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