Re: Return pg_control from pg_backup_stop().

On 10/28/26 07:38, Michael Paquier wrote:
> 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.

Are you sure valgrind is running? I'm not too familiar with build farm
configuration but it set 'use_valgrind' => undef, which seems to imply
it is off even if -DUSE_VALGRIND is also set.

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

This was my first thought, but I can't see why 8KiB on the stack would
be an issue. To me this looks a lot like a latent issue being exposed
because we've pushed things around on the stack a bit.

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

The patch looks good to me but I'm concerned it would just be masking
the real issue even if it works.

I'd be curious to see if the back branches run green when they run. It
would also be helpful to get a stack trace.

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.

Regards,
-David