Re: status of CURSORs after DISCONNECT - Mailing list pgsql-general

From George Neuner
Subject Re: status of CURSORs after DISCONNECT
Date
Msg-id lnnvtedcbvlreleta8t188odnb1r91nge9@4ax.com
Whole thread Raw
In response to status of CURSORs after DISCONNECT  (Matthias Apitz <guru@unixarea.de>)
List pgsql-general
On Thu, 28 Nov 2019 07:27:15 +0100, Matthias Apitz <guru@unixarea.de>
wrote:

>When an ESQL/C written process issues a
>
>EXEC SQL DISCONNECT [connection];
>
>do the opened CURSOR(s) still survive? We run into the problem that the
>father process issues DISCONNECT before forking children, the forked child
>CONNECTs to the same server and database again and "thinks" it has to CLOSE the
>CURSOR (perhaps a long standing bug in our application we port now from
>Sybase(...) to PostgreSQL).
>
>Thanks
>
>    matthias

Cursors are session specific so if the PG backend exits due to the
disconnect, any cursors it is managing will be closed.  

However, if you are using a connection pooler to keep PG backend
processes alive for reuse, then disconnecting does not necessarily end
the session.  In this case, you need to make sure any cursors are
closed because the next connection to the same backend process may
know nothing about them.

In any event, it's good practice always to close cursors when you are
done with them - if for no reason other than to release resources they
are holding.

George




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: status of CURSORs after DISCONNECT
Next
From: Adrian Klaver
Date:
Subject: Re: Rows violating Foreign key constraint exists