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

Hi,

> On 25 Sep 2026, at 16:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> 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.

Also happy to change this to return an error then if that is preferred?

Crashing seems very wrong, but an error seems fine?
I can change the patch then to do that.

Cheers,

Dirkjan