Re: status of CURSORs after DISCONNECT

From: George Neuner <gneuner2(at)comcast(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: status of CURSORs after DISCONNECT
Date: 2019-11-28 15:04:53
Message-ID: lnnvtedcbvlreleta8t188odnb1r91nge9@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 28 Nov 2019 07:27:15 +0100, Matthias Apitz <guru(at)unixarea(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2019-11-28 16:48:05 Re: Rows violating Foreign key constraint exists
Previous Message Tom Lane 2019-11-28 14:58:50 Re: status of CURSORs after DISCONNECT