Dirkjan Bussink <[email protected]> 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
