| From: | Tender Wang <tndrwang(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Backend crash in expanded_record_info functions |
| Date: | 2026-11-10 02:06:37 |
| Message-ID: | CAHewXNnDBGifxSqHvt1Xg4XmTL4=kQauQRo2kyWP4Yhz0bPG9w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While testing the current master with SQLsmith, I found a query that crashes
the backend. After running the regression tests, the issue can be
reproduced in the regression database with:
postgres=# \c regression
You are now connected to database "regression" as user "ubuntu".
regression=# SELECT expanded_record_info(2);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
(gdb) bt
#0 0x000062d8180991a3 in VARATT_IS_EXTERNAL (PTR=0x2) at
../../../../src/include/varatt.h:403
#1 0x000062d8180991c5 in VARATT_IS_EXTERNAL_EXPANDED_RW (PTR=0x2) at
../../../../src/include/varatt.h:436
#2 0x000062d81809a654 in DatumGetExpandedRecord (d=2) at expandedrecord.c:847
#3 0x000076332abce2b7 in expanded_record_info (fcinfo=0x62d845e6d230)
at regress.c:475
#4 0x000062d817cce8ba in ExecInterpExpr (state=0x62d845e6cca0,
econtext=0x62d845e6c480, isnull=0x7ffcbda7663f) at
execExprInterp.c:987
#5 0x000062d817cd1502 in ExecInterpExprStillValid
(state=0x62d845e6cca0, econtext=0x62d845e6c480, isNull=0x7ffcbda7663f)
at execExprInterp.c:2309
#6 0x000062d817d3bae2 in ExecEvalExprSwitchContext
(state=0x62d845e6cca0, econtext=0x62d845e6c480, isNull=0x7ffcbda7663f)
at ../../../src/include/executor/executor.h:452
#7 0x000062d817d3bc33 in ExecQual (state=0x62d845e6cca0,
econtext=0x62d845e6c480) at
../../../src/include/executor/executor.h:539
#8 0x000062d817d3c01b in ExecScanExtended (node=0x62d845e6c370,
accessMtd=0x62d817d3c08a <SeqNext>, recheckMtd=0x62d817d3c16f
<SeqRecheck>,
The function has a polymorphic argument, so a scalar value such as an
integer is accepted during function resolution. However,
expanded_record_info() passes the argument directly to
DatumGetExpandedRecord() through PG_GETARG_EXPANDED_RECORD(), assuming
that it is a composite Datum. The integer value 2 is consequently treated
as a pointer, causing an access at address 0x2 and crashing the backend.
The same issue exists in expanded_record_identity() and
expanded_record_field_text(), since they make the same assumption about
their polymorphic arguments.
The attached patch checks that the resolved argument type is a row
type before converting the Datum.
--
Thanks,
Tender Wang
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Validate-expanded-record-test-function-arguments.patch | text/plain | 2.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-11-10 02:51:13 | Re: Fix cumulative WAL statistics double-counting from parallel workers |
| Previous Message | Masahiko Sawada | 2026-11-10 01:46:12 | Re: Pass heap tuple counts to parallel vacuum as double |