| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Dirkjan Bussink <d(dot)bussink(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Server crash when describing a FETCH statement after its cursor is closed |
| Date: | 2026-10-01 05:26:20 |
| Message-ID: | ar3u_DU1fCIKkf3q@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | vignesh C | 2026-10-01 05:24:58 | Re: Proposal: Conflict log history table for Logical Replication |