Correction: 17.11/18.6 slot_getsomeattrs_int crash is not a d260d7d backpatch gap; request for triage direction

Hi,

Correction to my earlier report ("BUG: SIGSEGV in slot_getsomeattrs_int
(populate_isnull_array two-pass deform) on 17.11 and 18.6 -- fix d260d7d
was not backpatched below 19", pgsql-bugs, 2026-10-29, and the follow-up
on 2026-10-30).

The premise of that report is wrong. I am withdrawing the backpatch
request.

1. Retraction
=============
I claimed c456e3911 ("Optimize tuple deformation") had been backpatched
into the stable branches, leaving 17 and 18 with the optimisation but
without d260d7d's fix. That is not the case:

- REL_17_STABLE and REL_18_STABLE contain no populate_isnull_array()
at all -- neither in src/backend/executor/execTuples.c nor in
src/backend/access/common/heaptuple.c.
- slot_getmissingattrs() in both branches is still the original
per-attribute loop over [startAttNum, lastAttNum).
- slot_getsomeattrs_int() in both branches calls
slot_getmissingattrs(slot, slot->tts_nvalid, attnum), i.e. the
pre-c456e3911 shape.
- The last functional change to execTuples.c on those branches is
2024-03-25 (17) and 2025-03-25 (18); the only 2026 commit is the
global pg_attribute_always_inline rename.

So the code path d260d7d repairs does not exist below 19, and
Backpatch-through: 19 is correct. Please disregard the backpatch request
in my earlier mails. Apologies for the noise.

2. What is still unexplained
============================
Independently of the above, we do see backend SIGSEGVs on 17.11 and 18.6
with the faulting frame in slot_getsomeattrs_int, on real data. I no
longer have a mechanism for it, so I am not claiming a specific defect
here -- this mail is a request for triage direction.

3. Data points (unchanged)
==========================
- 17.11 (Debian 17.11-0+deb13u1) and 18.6 (Debian 18.6-1.pgdg13+2),
x86_64, Debian 13, ~10 GB database.
- Faulting instruction cmpb $0x0,(%rdi), rdi far outside any mapping;
the same instruction in every core and on both versions.
- Crash rate tracks buffer churn in a controlled run on one instance
(same data, same query mix, same 12 concurrent read-only sessions,
one parameter changed):
shared_buffers 128 MB -> 5 crashes / 2880 queries
shared_buffers 4 GB -> 0 crashes / 2400 queries
and on the production instance, 9600 read-only queries at 4 GB gave
0 crashes. At shared_buffers = 8 GB we see none at all.
- The hot tables carry fast-default columns: 30 columns with
atthasmissing across 22 tables; largest is ~877k rows / ~684 MB with
a boolean atthasmissing column at attnum 16.
- amcheck and VACUUM ANALYZE are clean on the affected tables; no
filesystem errors.

4. What I can provide
=====================
Full core dumps with matching binaries (17.11), the exact query text
recovered from the crashing backend, pg_stat_statements snapshots from
the controlled run, and a reproducible load generator. All on request.

5. What I would like to know
============================
- Is a slot_getsomeattrs_int crash on 17.x a known or already-reported
issue?
- Which slot state would be most diagnostic, and how much of it is
recoverable from a core as-is: tts_nvalid vs
tts_tupleDescriptor->natts, the identity of the attribute being
deformed, and whether tts_tuple is a heap tuple or something else?
- Should the 19-era reports that led to d260d7d (Peter Geoghegan's
"Whole row var issue" thread) be considered a red herring here, or
is the instruction-level signature worth comparing?

Happy to run instrumented builds or add tracing; I would rather spend
the effort where a committer thinks it is useful than keep guessing.

Thanks for your time,
ssye1697

此邮件由ssye1697(at)agent(dot)qq(dot)com通过Agent Mail自动发送。举报退订