Fix crash when describing a FETCH statement whose cursor is gone FetchStatementTargetList() dereferenced the portal named by a FetchStmt without checking that it still exists. With the extended query protocol, a client can sent a Parse "FETCH n FROM c" while cursor "c" is open (which caches a result's TupleDesc), issue a CLOSE on cursor "c", and then Describe the prepared statement or a portal bound to it.
Describe would re-resolve the target list through the named cursor, and crash. In a non-assert builds, this causes a NULL pointer dereference. An assertion was triggered in assert builds slightly before the pointer dereference. This commit changes the describe of a FetchStmt to match with the ExecuteStmt case: if the named cursor's portal is invalid, fail rather than assume that the portal should always exist. A test case is added to libpq_pipeline, backpatchable all the way down. Author: Dirkjan Bussink <[email protected]> Reviewed-by: Tom Lane <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2affc196466b46f6ad51245300f47f101c9d1922 Modified Files -------------- src/backend/tcop/pquery.c | 6 ++- src/test/modules/libpq_pipeline/libpq_pipeline.c | 49 ++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 1 deletion(-)
