| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Work around failure with SPARC in base backup code |
| Date: | 2026-10-29 00:44:55 |
| Message-ID: | E1xMEGF-00000001BTm-1ihb@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Work around failure with SPARC in base backup code
As reported by buildfarm members thorntail and billbug, both running
SPARC, 4a92c8c29bd0 is making the base backup code unstable on such
platforms.
The only suspicion I have at this stage is a stack frame issue, pointing
to something unrelated to 4a92c8c29bd0, that the addition of an array
worth a size of PG_CONTROL_FILE_SIZE within perform_base_backup() is
able to trigger.
thorntail complained with a SIGBUS, pointing at misaligned access, with
a sporadic failure. billbug complained with a SIGSEGV (siglongjmp issue
with PG_ENSURE_ERROR_CLEANUP perhaps?) in a more stable fashion.
The code is changed to use a palloc0() instead, which should cool down
the problem with the stack, hopefully. Unfortunately, I could not test
this hypothesis directly, lacking an environment able to do so.
Discussion: https://postgr.es/m/auGYf3jXtzLrr4gA@paquier.xyz
Backpatch-through: 15
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4b87b605bbe656fd0648dfce56ba7b7db700de8e
Modified Files
--------------
src/backend/backup/basebackup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2026-10-29 01:01:17 | pgsql: SQL/JSON: fix error handling when coercing to a domain fails sof |
| Previous Message | Amit Langote | 2026-10-29 00:25:27 | pgsql: SQL/JSON: always rethrow soft errors from DEFAULT expressions |