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