On Mon, Nov 13, 2023 at 01:01:32PM -0500, Bruce Momjian wrote:
> On Wed, Nov 1, 2023 at 08:47:33AM -0400, Bruce Momjian wrote:
> > On Tue, Oct 31, 2023 at 10:16:07PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
> > > >> What
On Wed, Nov 1, 2023 at 08:47:33AM -0400, Bruce Momjian wrote:
> On Tue, Oct 31, 2023 at 10:16:07PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
> > >> What I'm objecting to is removal of the bit about "if they need to be
> > >>
On Tue, Oct 31, 2023 at 10:16:07PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
> >> 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
> >>
Bruce Momjian writes:
> On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
>> 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
>>
On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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%
On Tue, Oct 31, 2023 at 01:58:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I modified your patch, attached, that I would like to apply to all
> > supported versions.
>
> This seems to have lost the information about what to do if these
> functions fail. I think probably the only
Bruce Momjian writes:
> I modified your patch, attached, that I would like to apply to all
> supported versions.
This seems to have lost the information about what to do if these
functions fail. I think probably the only possible failure cause
in nonblock mode is "unable to enlarge the buffer
On Wed, Jul 21, 2021 at 10:15:09AM +0900, Yugo NAGATA wrote:
> I understood that, although PQgetResult() also flushes the buffer, we still
> should call PQflush() beforehand because we would not like get blocked after
> calling PQgetResult(). Thanks.
I modified your patch, attached, that I would
Hello Alvaro,
On Tue, 20 Jul 2021 12:05:11 -0400
Alvaro Herrera wrote:
> On 2021-Jul-19, Yugo NAGATA wrote:
>
> > On Tue, 13 Jul 2021 11:59:49 +0900
> > Yugo NAGATA wrote:
>
> > > However, looking into the code, PQsendQuery seems not to return an error
> > > in non-bloking mode even if
On 2021-Jul-19, Yugo NAGATA wrote:
> On Tue, 13 Jul 2021 11:59:49 +0900
> Yugo NAGATA wrote:
> > However, looking into the code, PQsendQuery seems not to return an error
> > in non-bloking mode even if unable to send all data. In such cases,
> > pqSendSome will return 1 but it doesn't cause an
On Tue, 13 Jul 2021 11:59:49 +0900
Yugo NAGATA wrote:
> Hello,
>
> During reading the documentation of libpq [1] , I found the following
> description:
>
> In the nonblocking state, calls to PQsendQuery, PQputline, PQputnbytes,
> PQputCopyData, and PQendcopy will not block but instead return
Hello,
During reading the documentation of libpq [1] , I found the following
description:
In the nonblocking state, calls to PQsendQuery, PQputline, PQputnbytes,
PQputCopyData, and PQendcopy will not block but instead return an error
if they need to be called again.
[1]
13 matches
Mail list logo
