On Sun, Nov 3, 2024 at 11:40 PM Amul Sul wrote:
> +1 for the back-patching.
>
> For 0002, I think we could report the error a bit earlier — the better
> place might be in the else part of the following IF-block, IMO:
>
> /*
> * If s->header_length == 0, then this is a full file; otherwise, it's
>
On Fri, Nov 1, 2024 at 1:31 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Thu, Oct 31, 2024 at 12:06:25PM -0400, Robert Haas wrote:
> > On Thu, Oct 31, 2024 at 11:41 AM Bertrand Drouvot
> > wrote:
> > > I'm not sure about 0001 but I think 0002 deserves a back patch as I think
> > > it fits
> > > int
Hi,
On Thu, Oct 31, 2024 at 12:06:25PM -0400, Robert Haas wrote:
> On Thu, Oct 31, 2024 at 11:41 AM Bertrand Drouvot
> wrote:
> > I'm not sure about 0001 but I think 0002 deserves a back patch as I think
> > it fits
> > into the "low-risk fixes" category [0].
>
> I'm inclined to back-patch both
On Thu, Oct 31, 2024 at 11:41 AM Bertrand Drouvot
wrote:
> 0001 looks pretty straightforward and good to me.
Thanks for the review.
> What about moving the new comment just before the new "else if"?
Well, the block comment applies to the whole if-else if-else
construction. If we get too many el
Hi,
On Wed, Oct 30, 2024 at 03:50:53PM -0400, Robert Haas wrote:
> Hi,
>
> Here are two small patches to improve pg_combinebackup slightly.
>
> 0001: I noticed that there is some logic in reconstruct.c that
> constructs a pathname of the form a/b//c instead of a/b/c. AFAICT,
> this still works f
Hi,
Here are two small patches to improve pg_combinebackup slightly.
0001: I noticed that there is some logic in reconstruct.c that
constructs a pathname of the form a/b//c instead of a/b/c. AFAICT,
this still works fine; it just looks ugly. It's possible to get one of
these pathnames to show up
