On Thu, 28 Nov 2019 07:27:15 +0100, Matthias Apitz <guru@xxxxxxxxxxx> 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