Re: libpq: Which functions may hang due to network issues? - Mailing list pgsql-general

From Laurenz Albe
Subject Re: libpq: Which functions may hang due to network issues?
Date
Msg-id 36a1a59fcf09deec95b3abdec979d4d6b64a1a4a.camel@cybertec.at
Whole thread Raw
In response to Re: libpq: Which functions may hang due to network issues?  (Daniel Frey <d.frey@gmx.de>)
Responses Re: libpq: Which functions may hang due to network issues?  (Daniel Frey <d.frey@gmx.de>)
List 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




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions
Next
From: Matt Magoffin
Date:
Subject: Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions