Re: Return pg_control from pg_backup_stop().

On Friday, October 30th, 2026 at 4:34 AM, David Steele <david(at)pgbackrest(dot)org> wrote:

> On 10/30/26 00:08, Michael Paquier wrote:
> > On Thu, Oct 29, 2026 at 06:11:39PM +0000, Burd, Greg wrote:
> >> Validation of c97931c16d on the same machine: with it applied, three
> >> runs each of both reproductions give the WARNING and ERROR and no
> >> crash, and t/010_pg_basebackup.pl passes all 168 tests with no
> >> backend crash in the server logs. With it reverted, the same TAP run
> >> logs the SIGSEGV. The test still reports PASS in that case because
> >> it only checks that pg_basebackup fails.
> >
> > Ah, thanks for the in-depth investigation. So the previous guess was
> > really right. Candles work.
>
> Thank you, Greg! This is exactly the confirmation we needed.

Hey David, happy to help. As I said to Michael, now I can write off that
UltraSPARC 45 and the power it gobbles up on my taxes with proof that it
is used for work.

> I would encourage you to file a bug with gcc. I've found a few bugs and
> the gcc folks are really easy to work with. Since you have a repro it
> will be easy to produce the pre-processed output they want.

Sure, I'll carve out some time to do that.

> One bad thing -- even if they fix the bug, distros may choose not to
> back patch it (so it may already be fixed). I had to maintain a patch
> for a gcc bug on ppc64le for years before the affected distros EOL'd.
> That bug limited where I could use const, which was pretty annoying.

But that's the life of an open source developer, right? I signed up for
it so I can't complain. Or if I do, you should ignore me.

> >> I don't see a better fix on our side. A helper function with
> >> the array would also work, but palloc0() is simpler, and both rely on
> >> the same thing: no PG_TRY() frame larger than 4kB. In a core build
> >> on this machine, the only other function with a frame that large that
> >> calls sigsetjmp() is be_lo_export() (char buf[BUFSIZE]). Its code
> >> after sigsetjmp() reloads the constant, so it is fine today, but only
> >> by luck of register allocation. I haven't checked contrib or other
> >> GCC versions or as mentioned earlier against their bug system.
> >
> > Ugh. Even if the buffer itself is not used within the try/catch
> > block itself?
>
> Apparently so -- the failure of the base backup cancel test showed that.
> The buffer was never used and just the larger frame caused the problem.

I agree.

> > Getting entirely rid of the TRY/CATCH would lead to a
> > much nicer result overall: we'd be able to keep the local buffer. Or
> > perhaps go to the simpler solution of a palloc/pfree? I cannot
> > believe that this extra allocation would matter for lo_export() calls.
>
> palloc/pfree seems like the simpler solution.

+1

> > If you are proved to be right, it sounds to me that we ought to
> > fix and backpatch that as well, especially if there is nothing we can
> > do on the Postgres side. I don't believe in luck and magic when it
> > comes to software programming.
> I've attached a patch for be_lo_export(). Working around compiler bugs
> is never fun but I'm not sure what choice we have.

I've not reviewed the patch yet, but it is on my queue.

> Regards,
> -David

best.

-greg