On Thu, 11 Jan 2024 at 20:00, vignesh C wrote:
>
> On Thu, 13 Apr 2023 at 23:34, Fujii Masao wrote:
> >
> >
> >
> > On 2023/04/13 11:00, Kyotaro Horiguchi wrote:
> > > Agreed, it seems to be a leftover when we moved to parse_int_param()
> > > in that area.
> >
> > It looks like there was an
On Thu, 13 Apr 2023 at 23:34, Fujii Masao wrote:
>
>
>
> On 2023/04/13 11:00, Kyotaro Horiguchi wrote:
> > Agreed, it seems to be a leftover when we moved to parse_int_param()
> > in that area.
>
> It looks like there was an oversight in commit e7a2217978. I've attached a
> patch (0002) that
On Thu, Apr 13, 2023 at 2:04 PM Fujii Masao wrote:
> >> To clarify, are you suggesting that PQgetCancel() should
> >> only parse the parameters for TCP connections
> >> if cancel->raddr.addr.ss_family != AF_UNIX?
> >> If so, I think that's a good idea.
> >
> > You're right. I used connip in the
Hi, Fujii-san
> Regarding the WARNING message, another idea is to pass the return value
> of PQgetCancel() directly to PQcancel() as follows. If NULL is passed,
> PQcancel() will detect it and set the proper error message to errbuf.
> Then the warning message "WARNING: could not send cancel
On 2023/04/21 16:39, Jelte Fennema wrote:
In my opinion, PQconnectPoll and PQgetCancel should use the same
parsing function or PQconnectPoll should set parsed values, making
unnecessary for PQgetCancel to parse the same parameter
again.
Yes, I totally agree. So I think patch 0002 looks
> In my opinion, PQconnectPoll and PQgetCancel should use the same
> parsing function or PQconnectPoll should set parsed values, making
> unnecessary for PQgetCancel to parse the same parameter
> again.
Yes, I totally agree. So I think patch 0002 looks fine.
> Additionally, PQgetCancel should
At Mon, 17 Apr 2023 15:21:02 +0900, Etsuro Fujita
wrote in
> > >> Although the primary message is the same, the supplemental message pro=
> vides additional context that can help distinguish which function is report=
> ing the message.
> > >
> > > If the user is familiar with the
On Fri, Apr 14, 2023 at 11:28 PM Fujii Masao
wrote:
> On 2023/04/14 18:59, Etsuro Fujita wrote:
> >> The primary message basically should avoid reference to implementation
> >> details such as specific structure names like PGcancel, shouldn't it, as
> >> per the error message style guide?
> >
>
On 2023/04/14 18:59, Etsuro Fujita wrote:
The primary message basically should avoid reference to implementation details
such as specific structure names like PGcancel, shouldn't it, as per the error
message style guide?
I do not think that PGcancel is that specific, as it is described in
On Fri, Apr 14, 2023 at 3:19 AM Fujii Masao wrote:
> On 2023/04/13 15:13, Etsuro Fujita wrote:
> > I am not 100% sure that it is a good idea to use the same error
> > message "could not send cancel request" for the PQgetCancel() and
> > PQcancel() cases, because they are different functions. How
On 2023/04/13 15:13, Etsuro Fujita wrote:
I am not 100% sure that it is a good idea to use the same error
message "could not send cancel request" for the PQgetCancel() and
PQcancel() cases, because they are different functions. How about
"could not create PGcancel structure” or something
On 2023/04/13 11:00, Kyotaro Horiguchi wrote:
Agreed, it seems to be a leftover when we moved to parse_int_param()
in that area.
It looks like there was an oversight in commit e7a2217978. I've attached a
patch (0002) that updates PQconnectPoll() to use parse_int_param() for parsing
the
Hi Fujii-san,
On Wed, Apr 12, 2023 at 3:36 AM Fujii Masao wrote:
> However, if PQgetCancel() returned NULL and no cancel request was issued,
> I found that postgres_fdw could still wait for the reply to
> the cancel request, causing unnecessary wait time with a 30 second timeout.
Good catch!
>
At Wed, 12 Apr 2023 23:39:29 +0900, Fujii Masao
wrote in
> BTW, you can reproduce the issue even when using a TCP connection
> instead of a Unix domain socket by specifying a very large number
> in the "keepalives" connection parameter for the foreign server.
> Here is an example:
>
>
On 2023/04/12 12:00, Kyotaro Horiguchi wrote:
At Wed, 12 Apr 2023 03:36:01 +0900, Fujii Masao
wrote in
Attached patch fixes this issue. It ensures that postgres_fdw only
waits
for a reply if a cancel request is actually issued. Additionally,
it improves PQgetCancel() to set error messages
At Wed, 12 Apr 2023 03:36:01 +0900, Fujii Masao
wrote in
> Attached patch fixes this issue. It ensures that postgres_fdw only
> waits
> for a reply if a cancel request is actually issued. Additionally,
> it improves PQgetCancel() to set error messages in certain error
> cases,
> such as when
Hi,
When using postgres_fdw, in the event of a local transaction being
aborted while a query is running on a remote server,
postgres_fdw sends a cancel request to the remote server.
However, if PQgetCancel() returned NULL and no cancel request was issued,
I found that postgres_fdw could still
17 matches
Mail list logo
