Re: Return pg_control from pg_backup_stop().

On Wed, Oct 28, 2026 at 09:00:44AM +0900, Michael Paquier wrote:
> Hearing nothing, I have added that into my own pipeline and applies
> the fix down to v15. v14 has been left out, the branch going EOL soon
> with a problem that is extremely going to happen in practice does not
> give me a warm feeling. For v15 and v16, I have backpatched
> d2c1e18de9d1 first. The fix has been applied as of 4a92c8c29bd0.

Based on a sudden report from billbug, under Solaris 11, this gets
fun:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=billbug&dt=2026-10-28%2004%3A00%3A01

And we have a crash in a BASE_BACKUP command:
2026-10-28 05:23:30.548 CET [1429:4] LOG: client backend (PID 1498)
was terminated by signal 11: Segmentation Fault
2026-10-28 05:23:30.548 CET [1429:5] DETAIL: Failed process was
running: BASE_BACKUP ( LABEL 'pg_basebackup base backup', PROGRESS,
CHECKPOINT 'fast', WAIT 0, TABLESPACE_MAP, MANIFEST 'yes', TARGET
'client')

This runs under valgrind with -DRELCACHE_FORCE_RELEASE, and of course
I am not able to reproduce it with combinations of these three.

The closest thing that I can see in recent history would be
040932c31146. One possible explanation is PG_CONTROL_FILE_SIZE added
to the stack of perform_base_backup()? I'm still puzzled without more
information from valgrind, but if that's right we could try a
palloc0() instead.

My blind suggestion of fix would be the attached, that I cannot really
test. Thoughts or comments?
--
Michael