Robert Haas writes:
> On Wed, Dec 4, 2024 at 11:10 AM Nathan Bossart
> wrote:
>> D'oh, sorry. Even so, I think I'd still vote for back-patching the v17
>> commit that inadvertently fixed this.
> Gotcha. Let's see if anyone else votes.
+1 for a back-patch of 025584a16. It's made it through a
On Wed, Dec 4, 2024 at 11:10 AM Nathan Bossart wrote:
> D'oh, sorry. Even so, I think I'd still vote for back-patching the v17
> commit that inadvertently fixed this.
Gotcha. Let's see if anyone else votes.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Dec 04, 2024 at 09:29:50AM -0500, Robert Haas wrote:
> On Tue, Dec 3, 2024 at 5:26 PM Nathan Bossart
> wrote:
>> I'm only seeing this code in pg_checksums. Is that what you are proposing
>> to change?
>
> No. This code is present in src/backend/backup/basebackup.c in REL_16_STABLE.
D'o
On Tue, Dec 3, 2024 at 5:26 PM Nathan Bossart wrote:
> On Tue, Dec 03, 2024 at 11:39:43AM -0500, Robert Haas wrote:
> > If we want a narrower and thus less-risky fix, we could consider just
> > adjusting this code here:
> >
> > segmentno = atoi(segmentpath + 1);
> >
On Tue, Dec 03, 2024 at 11:39:43AM -0500, Robert Haas wrote:
> If we want a narrower and thus less-risky fix, we could consider just
> adjusting this code here:
>
> segmentno = atoi(segmentpath + 1);
> if (segmentno == 0)
> ereport(ERROR,
>
In 025584a168a4b3002e19350bb8db0ebf1fd10235, which shipped with v17, I
changed the way that a base backup decides whether files have
checksums. At the time, I thought this was harmless refactoring, but
it turns out that it was better than harmless. The old way can cause
pg_basebackup failures. To r
