Re: libpq: Which functions may hang due to network issues?

From: Daniel Frey <d(dot)frey(at)gmx(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq: Which functions may hang due to network issues?
Date: 2021-12-05 20:32:24
Message-ID: F58C28F1-E749-4ADB-B1D3-EACC3D5829AD@gmx.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On 5. Dec 2021, at 17:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Frey <d(dot)frey(at)gmx(dot)de> writes:
>> With all that said, I think that PostgreSQL/libpq should have a clear, documented way to get rid of a connection that is guaranteed to not hang. It has something similar for almost all other methods like opening connections, sending request, retrieving results. Why stop there?
>
> AFAICS, PQfinish() already acts that way, at least up to the same level of
> guarantee as you have for "all other methods". That is, if you previously
> set the connection into nonblock mode, it won't block.

OK, thanks Tom, that is at least something. I would still like this to be kinda documented/guaranteed, especially if nonblocking mode is required for this behavior (which is given in my case). But I guess that's not up to me, so I'll drop the topic and I'll just have to accept the status quo.

Thanks, Daniel

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message James Sewell 2021-12-06 00:40:41 Re: Max connections reached without max connections reached
Previous Message Tom Lane 2021-12-05 16:01:54 Re: libpq: Which functions may hang due to network issues?