| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Edwin Polkerman <edwin(dot)polkerman(at)splendiddata(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 16:49:49 |
| Message-ID: | CAOYmi+=prw7DdrMf2-k8E2jhbi6dQ2v03xJJYnC0ZwBe4GLwPg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Thu, Sep 3, 2026 at 4:55 AM Edwin Polkerman
<edwin(dot)polkerman(at)splendiddata(dot)com> wrote:
> Keeps me only wondering why the behaviour change in pg_basebackup is not implemented for PG14 to 16 as well.
We try to avoid big behavior changes in minor version updates.
> 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)?
Correct.
> 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
I'm happy to shepherd the conversation over to -hackers, and will do
that shortly. (I'm probably not the right person to drive it.)
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2026-09-03 17:10:36 | Do we want to avoid checksumming extra files in the datadir? [was: BUG #19647] |
| Previous Message | Andrey Rachitskiy | 2026-09-03 15:36:24 | Re: BUG #19651: to_date()/to_timestamp() silently accept out-of-range values for SSSSS, RM, IW and ID format fields |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-09-03 17:00:00 | Re: Stabilize 026_overwrite_contrecord test |
| Previous Message | Sami Imseih | 2026-09-03 16:49:33 | Re: Report index currently being vacuumed in pg_stat_progress_vacuum |