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

From Michael Paquier
Subject Re: Server crash when describing a FETCH statement after its cursor is closed
Date
Msg-id ar3u_DU1fCIKkf3q@paquier.xyz
Whole thread
In response to Re: Server crash when describing a FETCH statement after its cursor is closed  (Dirkjan Bussink <d.bussink@gmail.com>)
Responses Re: Server crash when describing a FETCH statement after its cursor is closed
List pgsql-hackers
On Sat, Sep 26, 2026 at 09:23:42AM +0200, Dirkjan Bussink wrote:
> Alright, here is a patch that now explicit returns an error when the portal
> is already closed, matching what ExecuteStmt does.

Sounds acceptable to me to return an error and having a test this way.
Something that the other test subroutines of libpq_pipeline do and
that your new test subroutine does not do is the use of a fprintf() to
log the beginning of the test.  That's a minor point.

libpq_pipeline is OK for the test location, we already have a few
things that don't care about pipelining like the protocol version and
its README also says that.

Another thing I was wondering is if any of the psql meta-commands
could be of some help here.  However, as far as I can see, these
cannot help because psql sends more describes than what we need to
trigger the problem.  Unfortunate, but again no big deal with libpq
able to wrap the job.

Tom, were you planning to double-check the contents of this thread?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: Jobin Augustine
Date:
Subject: Re: test: avoid redundant standby catchup in 049_wait_for_lsn