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

From Dirkjan Bussink
Subject Re: Server crash when describing a FETCH statement after its cursor is closed
Date
Msg-id AEE53B19-A4F4-4A77-A73E-053300E715DD@gmail.com
Whole thread
In response to Re: Server crash when describing a FETCH statement after its cursor is closed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

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




pgsql-hackers by date:

Previous
From: shihao zhong
Date:
Subject: Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Next
From: Ayush Tiwari
Date:
Subject: Re: Cleaning up pgcrypto/crypt-des.c to avoid compiler warnings