Re: Return pg_control from pg_backup_stop().

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.

> 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? 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. I don't believe in luck and magic when it
comes to software programming.

Thoughts?
--
Michael