From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Daniel Frey <d(dot)frey(at)gmx(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: libpq: Which functions may hang due to network issues? |
Date: | 2021-12-04 21:43:48 |
Message-ID: | 36a1a59fcf09deec95b3abdec979d4d6b64a1a4a.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2021-12-03 at 21:33 +0100, Daniel Frey wrote:
> But the real issue, at least for me, is PQfinish(). Considering that my application is not
> allowed to hang (or crash, leak, ...), what should I do in case of a timeout?
I am tempted to say that you shouldn't use TCP with the requirement that it should not hang.
> I have existing
> connections and at some point the network connections stop working (e.g. due to a firewall
> issue/reboot), etc. If I don't want a resource leak, I *must* call PQfinish(), correct?
> But I have no idea whether it might hang. If you don't want to guarantee that PQfinish()
> will not hang, then please advise how to use libpq properly in this situation. If there
> some asynchronous version of PQfinish()? Or should I handle hanging connections differently?
You could start a separate process that has your PostgreSQL connection and kill it if it
times out. But then you'd have a similar problem communicating with that process.
A normal thing to do when your database call times out or misbehaves in other ways is
to give up, report an error and die (after some retries perhaps).
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Magoffin | 2021-12-04 21:55:38 | Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions |
Previous Message | Tom Lane | 2021-12-04 20:04:15 | Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions |