Re: Server crash when describing a FETCH statement after its cursor is closed

Dirkjan Bussink <d(dot)bussink(at)gmail(dot)com> writes:
> 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:

Thanks for the report.

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

I'm not convinced by this blithe assertion "not our business to raise
error". The adjacent case for ExecuteStmt *will* raise an error if
it can't find the prepared statement; why shouldn't this case act like
that one? IOW, the sequence of client operations that you show is
invalid, and I think we ought to push back on that accordingly.

regards, tom lane