Re: Question about non-blocking mode in libpq

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about non-blocking mode in libpq
Date: 2023-11-01 01:55:49
Message-ID: ZUGwJY1qmzUMgk0Y@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Okay, I added "_successful_ calls", attached. I am not sure what else
> > to add.
>
> What I'm objecting to is removal of the bit about "if they need to be
> called again". That provides a hint that retry is the appropriate
> response to a failure. Admittedly, it's not 100% clear, but your
> version makes it 0% clear.

I thought the original docs said you had to re-call on failure (it would
not block but it would fail if it could not be sent), while we are now
saying that it will be queued in the input buffer.

Is retry really something we need to mention now? If out of memory is
our only failure case now ("unable to enlarge the buffer because OOM"),
is retry really a realistic option?

Am I missing something?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-11-01 02:16:07 Re: Question about non-blocking mode in libpq
Previous Message Tom Lane 2023-11-01 01:11:06 Re: Question about non-blocking mode in libpq