Re: Return pg_control from pg_backup_stop().

Am 28.10.2026 um 09:56 schrieb David Steele:
> 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.

sorry. core was disabled. enabled now for the future.
interesting: my second solaris11/sparc animal is fine.
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=margay&br=master

Best regards,
Marcel