pgsql: Fix crash when describing a FETCH statement whose cursor is gone

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 <d(dot)bussink(at)gmail(dot)com>
Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Reviewed-by: Michael Paquier <michael(at)paquier(dot)xyz>
Discussion: https://postgr.es/m/7DE248EB-7509-4F8A-9F37-4694A40BBAB7@gmail.com
Backpatch-through: 14

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/50d6e533e4d9a0f70d798c534254007c83c0d428

Modified Files
--------------
src/backend/tcop/pquery.c | 6 ++-
src/test/modules/libpq_pipeline/libpq_pipeline.c | 49 ++++++++++++++++++++++++
2 files changed, 54 insertions(+), 1 deletion(-)