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?
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 |