Server crash when describing a FETCH statement after its cursor is closed - Mailing list pgsql-hackers

From Dirkjan Bussink
Subject Server crash when describing a FETCH statement after its cursor is closed
Date
Msg-id 7DE248EB-7509-4F8A-9F37-4694A40BBAB7@gmail.com
Whole thread
Responses Re: Server crash when describing a FETCH statement after its cursor is closed
List pgsql-hackers
Hi,

The following extended-protocol sequence crashes a backend (SIGSEGV
in production builds, assertion failure in assert-enabled ones), and
the postmaster terminates all other sessions for crash recovery:

    Query     BEGIN
    Query     DECLARE c CURSOR FOR SELECT id FROM t ORDER BY id
    Parse     ""  "FETCH 5 FROM c"
    Bind      portal "p", statement ""
    Sync
    Query     CLOSE c
    Describe  portal "p"
    Sync                        -> connection drops; server log shows
                                   "terminated by signal 11", then
                                   "terminating any other active
                                   server processes"

Describing the prepared statement instead of the portal crashes the
same way.  Reproduced on REL_18_STABLE (18.6) and current master, 
the code is identical on all supported branches.

At Bind time, PortalStart() copies the cursor's tuple descriptor into
the portal via UtilityTupleDescriptor(), which deliberately tolerates
a missing cursor.  But Describe re-resolves the target list through
FetchStatementTargetList() (tcop/pquery.c), whose FetchStmt branch does:

    subportal = GetPortalByName(fstmt->portalname);
    Assert(PortalIsValid(subportal));
    return FetchPortalTargetList(subportal);

With the cursor closed, GetPortalByName() returns NULL and the Assert
is compiled out in production builds, so FetchPortalTargetList()
dereferences NULL->strategy.  The statement variant reaches the same
branch via CachedPlanGetTargetList().

The attached patch replaces the Assert with a runtime check returning
NIL, mirroring the guard in UtilityTupleDescriptor(). A regression
test is included.

-- 
Cheers,

Dirkjan Bussink


Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: Remove invalid SS2/SS3 handling from EUC-KR routines
Next
From: Ayush Tiwari
Date:
Subject: Re: remove_useless_joins vs. bug #19560