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>, 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-06 10:08:28
Message-ID: 5680D61C-3BC3-426D-877C-3712B10FABC5@gmx.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5. Dec 2021, at 21:32, Daniel Frey <d(dot)frey(at)gmx(dot)de> wrote:
>
>> 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.

One more question about this: What is the purpose of *not* using nonblocking mode with PQfinish()? Is there any benefit to the user in waiting for something? Or could it make sense for PQfinish() to always use nonblocking mode internally?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Avi Weinberg 2021-12-06 14:50:35 Are Foreign Key Disabled During Logical Replication Initial Sync?
Previous Message James Sewell 2021-12-06 05:47:37 Re: Max connections reached without max connections reached