Re: Return pg_control from pg_backup_stop().

On Thursday, October 29th, 2026 at 7:08 PM, Michael Paquier <michael(at)paquier(dot)xyz> 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.

Hey Michael, sure thing. It's why I bought the UltraSPARC 45, oddly
enough!

> So the previous guess was really right.

Yes, you have a talent for many things including guessing fixes to
obscure issues.

> Candles work.

Indeed they do. :)

> > 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?

I could test if you'd like.

> 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.
>
> 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.

Better safe than sorry. Even if I submit a bug to GCC and they fix it
there it will take time to get that shipped and you have people who rarely
update, etc. etc.

> I don't believe in luck and magic when it comes to software programming.

Nope, just 1s and 0s.

> Thoughts?
> --
> Michael

best.

-greg