Re: Return pg_control from pg_backup_stop().

On 10/28/26 11:56, Michael Paquier wrote:
> On Wed, Oct 28, 2026 at 08:56:25AM +0000, David Steele wrote:
>> I've CC'd billbug's owner. The HEAD run with the 2026-10-28 04:00 UTC
>> snapshot crashed a client backend (PID 1498) running BASE_BACKUP with
>> SIGSEGV during src/bin/pg_basebackup/t/010_pg_basebackup.pl, but no
>> backtrace made it into the logs. Could you check whether a core file was
>> written and get a backtrace from it? If no core was written then the
>> coreadm settings may be redirecting or suppressing it. Any additional info
>> you can provide would be greatly appreciated.
>
> We have what looks like a second report on HEAD and v19, different
> pattern:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=thorntail&dt=2026-10-28%2006%3A31%3A23&stg=recovery-check
>
> From 001's primary logs:
> 2026-10-28 10:44:13.113 MSK [1706208:4] LOG: client backend (PID
> 1706227) was terminated by signal 10: Bus error
> 2026-10-28 10:44:13.113 MSK [1706208:5] DETAIL: Failed process was
> running: BASE_BACKUP (CHECKPOINT 'fast', MAX_RATE 32);
>
> If something else is going on, I'm not quite sure what it is yet.
thorntail is also SPARC so this failure narrows things down quite a bit.

The test that crashed is "base backup cleanly canceled". This test is
designed to be cancelled in the middle so it is unlikely that it ever
got to the new code, which isolates the extra 8KiB on the stack as the
likely cause. Well, that already seemed clear but this is additional
confirmation.

On the cancel path the only runtime difference from the prior code is
the size of perform_base_backup()'s frame. The new 8kB buffer is
declared inside PG_ENSURE_ERROR_CLEANUP() so the error from the cancel
siglongjmp()s back into the larger frame. A bus error on SPARC is
usually an alignment trap, so my guess is that the larger frame exposes
an alignment problem somewhere in the unwinding. That fits with my
earlier suspicion that this is a latent issue exposed by moving things
around on the stack.

Since v19 is failing as well this is not specific to master. I think we
should go ahead with your palloc0() patch to get the buildfarm green
again. It takes the buffer out of the frame entirely. It may well be
masking something, but that is better investigated with a backtrace than
with a red buildfarm. Perhaps Noah can get one from thorntail.

[This analysis was aided by Claude but I double-checked the details.]

Regards,
-David