x27;Fabien COELHO' ;
> 'pgsql-hack...@postgresql.org'
> Cc: Yahorau, A. (IBA)
> Subject: RE: Timeout parameters
>
> Hi, Fabien.
>
> Thank you for your review.
> And I'm very sorry to have kept you waiting so long.
>
>
> About "soc
Hi, Fabien.
The next CF will start so I want to restart the discussion.
> About "socket_timeout"
> If you face the following situation, this parameter will be needed.
If you feel that this situation can't happen or the use case is too limited,
please point out so.
> > I think that there is some
I'm not sure I understand the use case you have that needs these new
extensions.
If you face the following situation, this parameter will be needed.
1. The connection between the server and the client has been established
normally.
2. A server process has been received SQL statement.
3. The
こんにちは Royhei,
About the patches: you are expected to send consistent patches, i.e. one
feature with its associated documentation, not two separate features and
another patch for documenting them.
--
Fabien.
Hi,
On Tue, Dec 25, 2018 at 2:59 AM, Fabien COELHO wrote:
> >> 4. The client wants to close the connection while leaving the job to
> >> the server.
> >> In this case, "statement_timeout" can't satisfy at line 4.
>
> Why?
> ISTM that "leaving the job" to the server with a client-side connection
>
Hi Fabien.
On Wed, Dec 26, 2018 at 3:02 AM, Fabien COELHO wrote:
> About the patches: you are expected to send consistent patches, i.e. one
> feature with its associated documentation, not two separate features and
> another patch for documenting them.
Thank you for teaching me.
I rewrote patches
Hello Ryohei,
4. The client wants to close the connection while leaving the job to
the server.
In this case, "statement_timeout" can't satisfy at line 4.
Why?
ISTM that "leaving the job" to the server with a client-side connection
closed is basically an abort, no different from what server-s
From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> I still do not understand the use-case specifics: for me, aborting the
> connection, or a softer cancelling the statement, will result in the
> server stopping the statement, so the server does NOT "continue the job",
> so I still do not see how it
se this option together with
keepalive.
Best regards,
Andrei Yahorau
From: "Tsunakawa, Takayuki"
To: 'Fabien COELHO' , "Nagaura, Ryohei"
,
Cc: "'pgsql-hack...@postgresql.org'" ,
"ayaho...@ibagroup.eu"
Date: 27/12/
On Thursday, April 4, 2019 5:20PM (GMT+9), Ryohei Nagaura wrote:
> > From: Fabien COELHO
> > * About socket_timeout v12 patch, I'm not sure there is a consensus.
> I think so too. I just made the patch being able to be committed anytime.
>
> Finally, I rebased all the patches because they have c
On Fri, Apr 05, 2019 at 04:39:36AM +, Jamison, Kirk wrote:
> I just checked and confirmed that the TCP USER TIMEOUT patch set v20
> works. Although you should capitalize "linux" to "Linux" as already
> mentioned before. The committer can also just fix that very minor
> part, if patch is deeme
From: Michael Paquier [mailto:mich...@paquier.xyz]
> The first letter should be upper-case.
Thank you for taking care of this patch, and sorry to cause you trouble to fix
that...
> to me that socket_timeout_v14.patch should be rejected as it could cause
> a connection to go down with no actual
On Fri, Apr 05, 2019 at 07:34:48AM +, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
>> The first letter should be upper-case.
>
> Thank you for taking care of this patch, and sorry to cause you
> trouble to fix that...
I have just committed the GUC and libpq
From: Michael Paquier [mailto:mich...@paquier.xyz]
> I have just committed the GUC and libpq portion for TCP_USER_TIMEOUT after
> a last lookup, and I have cleaned up a couple of places.
Thank you for further cleanup and committing.
> For the socket_timeout stuff, its way of solving the problem
Hi, Michael-san.
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> I have just committed the GUC and libpq portion for TCP_USER_TIMEOUT after a
> last lookup, and I have cleaned up a couple of places. It is a bit
> disappointing
> to see the option supported on Linux, but not on Windows, So
Hello Ryohei,
I took a look at your changes and I have some notes.
I faced the same issue as you faced. In my opinion hanging of a client is
quite critical case and it needs to be overcame.
TCP_USER_TIMEOUT option helps to overcome this problem and I agree with
you that it needs to be suppor
Hi Andrei,
Thank you for response.
> TCP_USER_TIMEOUT option helps to overcome this problem and I agree with
> you that it needs to be supported within PostgreSQL.
I'm glad to your agreement.
> Nevertheless, it is necessary to take into account that the option
> TCP_USER_TIMEOUT is supported by
Hi Andrei,
First, I inform you that I may not contact for the following period:
From November 1st to November 19th
Second, I noticed my misunderstanding in previous mail.
> > Nevertheless, it is necessary to take into account that the option
> > TCP_USER_TIMEOUT is supported by Linux kernel start
Hello Ryohei,
I'd like to suggest introducing two parameters to handle client-server
communication timeouts.
I'm generally fine with giving more access to low-level parameters to
users. However, I'm not sure I understand the use case you have that needs
these new extensions.
"socket_tim
Hi,
> > tcp_socket_timeout (integer)
> >
> > Terminate and restart any session that has been idle for more than
> > the specified number of milliseconds to prevent client from infinite
> > waiting for server due to dead connection. This can be used both as
> > a brute force global query timeout an
From: Jamison, Kirk/ジャミソン カーク
> Although I did review and followed the suggested way in previous email
> way back (which uses root user) and it worked as intended, I'd also like
> to hear feedback also from Fabien whether it's alright without the test
> script, or if there's another way we can test
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> I am not very familiar with the PostgreSQL source code. Nevertheless, the
> main idea of this parameter is clear for me - closing a connection when
> the PostgreSQL server does not response due to any reason. However, I have
> not
On Friday, February 22, 2019 9:46 AM (GMT+9), Tsunakawa, Takayuki wrote:
> > Terminate any session that has been idle for more than the
> > specified number of seconds to prevent client from infinite
> > waiting for server due to dead connection. This can be used both as a
> > brute force globa
From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com]
> socket_timeout (integer)
libpq documentation does not write the data type on the parameter name line.
> Terminate any connection that has been inactive for more than the specified
> number of seconds to prevent client from infinite waiting
Hi, all.
Thank you for discussion.
I made documentation about socket_timeout and reflected Tsunakawa-san's comment
in the new patch.
# Mainly only fixing documentation...
The current documentation of socket_timeout is as follows:
socket_timeout
Controls the number of second of client's waiting ti
On Monday, February 25, 2019 1:49 PM (GMT+9), Nagaura, Ryohei wrote:
> Thank you for discussion.
> I made documentation about socket_timeout and reflected Tsunakawa-san's
> comment in the new patch.
> # Mainly only fixing documentation...
> The current documentation of socket_timeout is as follows
Hi, kirk-san.
> From: Jamison, Kirk
> $ git apply ../socket_timeout_v5.patch
> fatal: corrupt patch at line 24
> --> l24: diff --git a/src/interfaces/libpq/fe-connect.c
> --> b/src/interfaces/libpq/fe-connect.c
How about applying by "patch -p1"?
I have confirmed that my patch could be applied in
This mail is the same as
https://www.postgresql.org/message-id/EDA4195584F5064680D8130B1CA91C453EBE79%40G01JPEXMBYT04
I resend because the mail didn't be reflected.
Hi, kirk-san.
> From: Nagaura, Ryohei This is my bad.
> I'll remake it.
> Very sorry for the same mistake.
I remade the patches a
Hi Nagaura-san,
Your socket_timeout patch still does not apply either with
git or patch command. It says it's still corrupted.
I'm not sure about the workaround, because the --ignore-space-change
and --ignore-whitespace did not work for me.
Maybe it might have something to do with your editor when
Hi, kirk-san.
Thank you for review.
> From: Jamison, Kirk
> Your socket_timeout patch still does not apply either with git or patch
> command. It
> says it's still corrupted.
> I'm not sure about the workaround, because the --ignore-space-change and
> --ignore-whitespace did not work for me.
>
Hi,
I rewrote two TCP_USER_TIMEOUT patches.
I changed the third argument of setsockopt() from 18 to TCP_USER_TIMEOUT.
This revision has the following two merits.
* Improve readability of source
* Even if the definition of TCP_USER_TIMEOUT is changed, it is not affected.
e.g., in the current lin
Hello Ryohei-san,
There are three independent patches in this thread.
About the socket timeout patch v7:
Patch applies & compiles cleanly. "make check" is ok, although there are
no specific tests, which is probably ok. Doc build is ok.
I'd simplify the doc first sentence to:
""" Number of
Hello again Ryohei-san,
About the tcp_user_timeout libpq parameter v8.
Patch applies & compiles cleanly. Global check is ok, although there are
no specific tests.
Documentation English can be improved. Could a native speaker help,
please?
ISTM that the documentation both states that it w
About the tcp_user_timeout libpq parameter v8.
Basically same thing about the tcp_user_timeout guc v8, especially: do you
have any advice about how I can test the feature, i.e. trigger a timeout?
Patch applies & compiles cleanly. Global check is ok, although there are no
specific tests.
On Sunday, March 3, 2019 4:09PM (GMT+9), Fabien COELHO wrote:
>Basically same thing about the tcp_user_timeout guc v8, especially:
> do you have any advice about how I can test the feature, i.e.
> trigger a timeout?
>
>> Patch applies & compiles cleanly. Global check is ok, although there
>> are
Hi, Fabien-san.
About TCP_USER_TIMEOUT:
> From: Fabien COELHO
> I could not really test the feature, i.e. I could not trigger a timeout.
> Do you have a suggestion on how to test it?
Please see the previous mail[1] or current kirk-san's mail.
About socket_timeout:
> From: Fabien COELHO
> are ac
Hello Ryohei-san,
About socket_timeout:
From: Fabien COELHO
are actually finished. I cannot say that I'm thrilled by that behavior. ISTM
that libpq
should at least attempt to cancel the query
Would you please tell me why you think so?
As I understand the "client-side timeout" use-case, a
Hi, Fabien-san.
> From: Fabien COELHO
> As I understand the "client-side timeout" use-case, as distinct from
> network-issues-related timeouts proposed in the other patches, the point is
> more
> or less to deal with an overloaded server.
The main purpose of this parameter is to avoid client's w
Hello Ryohei-san,
I understand the main aim of your suggestion that a client application has
to do a lot of work except making quires to the database. I agree with you
that "client-side timeout" has to be integrated into the PostgreSQL server
and libpq.
I'm with Fabien that "client-side timeout
Hello, Mikalai-san.
Thank you for your mail.
> From: mikalaike...@ibagroup.eu
> I'm with Fabien that "client-side timeout" seems unsafe. Also I agree with
> Fabien
> that quire can take much time to be processed by the PosgtreSQL server and it
> is
> a normal behavior. There is possible that p
On Sun, Mar 10, 2019 at 10:25 PM Nagaura, Ryohei
wrote:
> The main purpose of this parameter is to avoid client's waiting for DB server
> infinitely, not reducing the server's burden.
> This results in not waiting end-user, which is most important.
+1. If the server fails to detect that the cli
On Wed, Feb 27, 2019 at 10:07 PM Nagaura, Ryohei
wrote:
> I rewrote two TCP_USER_TIMEOUT patches.
> I changed the third argument of setsockopt() from 18 to TCP_USER_TIMEOUT.
>
> This revision has the following two merits.
> * Improve readability of source
> * Even if the definition of TCP_USER_TIM
Hello Nagaura-san.
Thank you for your response.
The main idea of my comment was to avoid handling logical errors (
"client-side timeout") in advance to the detection of network problems
Therefore, I suggested setting "client-side timeout" greater of equal to
the TCP_USER_TIMEOUT or note abo
Hello Robert,
wrote:
The main purpose of this parameter is to avoid client's waiting for DB server
infinitely, not reducing the server's burden.
This results in not waiting end-user, which is most important.
+1. If the server fails to detect that the client has gone away,
that's the serv
Hello Mikalai-san.
> From: mikalaike...@ibagroup.eu
> The main idea of my comment was to avoid handling logical errors (
> "client-side
> timeout") in advance to the detection of network problems
> Therefore, I suggested setting "client-side timeout" greater of equal to the
> TCP_USER_TIMEOU
Hello Robert-san.
> From: Robert Haas
> So this says that it works on systems that have TCP_USER_TIMEOUT or an
> equivalent socket option and that it also works on Windows, and then a few
> lines
> later
>
> + This parameter is not supported on Windows, and must be zero.
>
> This say
On Wed, Mar 13, 2019 at 2:05 AM Fabien COELHO wrote:
> Also, I do not see the downside of sending a cancel query before severing
> the connection. If it is not processed, too bad, but if it is then it is
> for the better.
If the network connection is dead, which is the situation the patch
intends
Hello Robert,
Also, I do not see the downside of sending a cancel query before severing
the connection. If it is not processed, too bad, but if it is then it is
for the better.
If the network connection is dead, which is the situation the patch
intends to detect,
Hmmm... ISTM that we are n
Hello Fabien-san.
The 2nd patch is 700 KB, I think that there is a unvoluntary file copy.
If the user reconnects, eg "\c db", the setting is lost. The
re-connection handling should probably take care of this parameter, and maybe
others.
I think your opinion is reasonable, but it seems not
On Wed, Mar 13, 2019 at 1:25 PM Fabien COELHO wrote:
> Hmmm... ISTM that we are not talking about the same patch...
You are correct! I was talking about the patches that allow user
control of TCP_USER_TIMEOUT, which is apparently totally different
from the socket_timeout patch that you're talkin
From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> >> If the user reconnects, eg "\c db", the setting is lost. The
> >> re-connection handling should probably take care of this parameter, and
> maybe others.
> > I think your opinion is reasonable, but it seems not in this thread.
>
> HI think that
From: Robert Haas [mailto:robertmh...@gmail.com]
> The first thing I notice about the socket_timeout patch is that the
> documentation is definitely wrong:
Agreed. I suppose the description should be clearer about:
* the purpose and what situation this timeout will help: not for canceling a
lon
On Wed, Mar 13, 2019 at 10:20 PM Tsunakawa, Takayuki
wrote:
> I think the purpose of socket_timeout is to avoid infinite or unduely long
> wait and return response to users, where other existing timeout parameters
> wouldn't help. For example, OS's process scheduling or paging/swapping
> probl
From: Robert Haas [mailto:robertmh...@gmail.com]
> But that's not what it will do. As long as the server continues to
> dribble out protocol messages from time to time, the timeout will
> never fire no matter how much time passes. I saw a system once where
> every 8kB read took many seconds to co
At Thu, 14 Mar 2019 03:33:20 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FBC4191@G01JPEXMBYT05>
> From: Robert Haas [mailto:robertmh...@gmail.com]
> > But that's not what it will do. As long as the server continues to
> > dribble out protocol messages from time to ti
HI think that your patch is responsible for the added option at least.
I agree that the underlying issue that other parameters should probably
also be reused, which would be a bug fix, does not belong to this thread.
This doesn't seem to be a bug. \connect just establishes a new connection,
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> If so, in turn the socket_timeout doesn't work as expected? I
> understand that what is proposed here is to disconnect after that
> time of waiting for *the first tuple* of a query, regardless of
> it is a long query or network fail
From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> I think that the typical use-case of \c is to connect to another database
> on the same host, at least that what I do pretty often. The natural
> expectation is that the same "other" connection parameters are used,
> otherwise it does not make much
Hello, all.
The main subject of discussion in this thread relates to the
'socket_timeout'. As I understand there is no any hesitation about
applying TCP_USER_TIMEOUT into the PostgreSQL.
We have been waiting for applying TCP_USER_TIMEOUT in PostgreSQL for about
6 moths.
Fabien, I was wondering
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> > For example, OS issues such as abnormally (buggy) slow process scheduling
> or paging/swapping that prevent control from being passed to postgres. Or,
> abnormally long waits on lwlocks in postgres. statement_timeout doesn't
> t
Hello.
At Thu, 14 Mar 2019 12:33:38 +0300, mikalaike...@ibagroup.eu wrote in
> Hello, all.
>
> The main subject of discussion in this thread relates to the
> 'socket_timeout'. As I understand there is no any hesitation about
> applying TCP_USER_TIMEOUT into the PostgreSQL.
> We have been wait
Hello.
At Thu, 14 Mar 2019 09:42:44 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FBC7626@G01JPEXMBYT05>
> From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> > > For example, OS issues such as abnormally (buggy) slow process scheduling
> > or paging/swa
Hello, Takayuki.
> > > For example, OS issues such as abnormally (buggy) slow process
scheduling
> > or paging/swapping that prevent control from being passed to postgres.
Or,
> > abnormally long waits on lwlocks in postgres. statement_timeout
doesn't
> > take effect while waiting on a lwlock
On Wed, Mar 13, 2019 at 11:33 PM Tsunakawa, Takayuki
wrote:
> I understood hat the example is about an SELECT that returns multiple rows.
> If so, statement_timeout should handle it, shouldn't it?
Yes. If you want a query timeout, you should use statement_timeout, not this.
> > I think the us
One other thing -- I looked a bit into the pgsql-jdbc implementation
of a similarly-named option, and it does seem to match what you are
proposing here. I wonder what user experiences with that option have
been like.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgre
From: Robert Haas [mailto:robertmh...@gmail.com]
> One other thing -- I looked a bit into the pgsql-jdbc implementation
> of a similarly-named option, and it does seem to match what you are
> proposing here. I wonder what user experiences with that option have
> been like.
One case I faintly reca
From: Robert Haas [mailto:robertmh...@gmail.com]
> Now you might say - what if the server is stopped not because of
> SIGSTOP but because of some other reason, like it's waiting for a
> lock? Well, in that case, the database server is still functioning,
> and you will not want the connection to be
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> Do you mind me asking you whether you have thought that solving your problem
> can lead to the problem in the other user applications?
> Let's imagine a possible problem:
> 1. end-user sets 'socket_timeout' only for current session
Hello Takayuki-san,
> Yes, so I think it would be necessary to describe how to set
socket_timeout with relation to other timeout parameters -- socket_timeout
> statement_timeout, emphasizing that socket_timeout is not for canceling
long-running queries but for returning control to the client.
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> In case of failure PQcancel() terminates in 'socket_timeout'. So, control
> to the end-user in such a failure situation will be returned in 2 *
> 'socket_timeout' interval. It is much better than hanging forever in some
> specific c
> Oops, unfortunately, PQcancel() does not follow any timeout
parameters... It uses a blocking socket.
> Also, I still don't think it's a good idea to request cancellation.
socket_timeout should be sufficiently longer than the usually expected
query execution duration. And long-running querie
Hello,
Fabien, I was wondering whether you can apply TCP_USER_TIMEOUT patch and
continue discussion about 'socket_timeout'?
I can apply nothing, I'm just a small-time reviewer.
Committers on the thread are Michaël-san and Robert, however I'm not sure
that they are very sensitive to "please
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> Based on your comment it seems to me that 'socket_timeout' should be
> connected with statement_timeout. I mean that end-user should wait
> statement_timeout + 'socket_timeout' for returning control. It looks much
> more safer for m
On Saturday, March 16, 2019 5:40 PM (GMT+9), Fabien COELHO wrote:
> > Fabien, I was wondering whether you can apply TCP_USER_TIMEOUT patch
> > and continue discussion about 'socket_timeout'?
> I can apply nothing, I'm just a small-time reviewer.
> Committers on the thread are Michaël-san and Ro
On Sun, Mar 17, 2019 at 9:08 PM Jamison, Kirk wrote:
> The main argument here is about the security risk of allowing socket timeout
> to cancel valid connections, right?
I don't think so. I think it's just a weirdly-design parameter
without a really compelling use case. Enforcing limits on the
From: Robert Haas [mailto:robertmh...@gmail.com]
> I don't think so. I think it's just a weirdly-design parameter
> without a really compelling use case. Enforcing limits on the value
> of the parameter doesn't fix that. Most of the reviewers who have
> opined so far have been somewhere between
Hi,
First, thank you for your insightful discussion.
I remade patches and attached in this mail.
> From: Tsunakawa, Takayuki
> OTOH, it may be better to commit the tcp_user_timeout patch when
> Nagaura-san has refined the documentation, and then continue
> socket_timeout.
Yes, I want to commit TC
Hi Nagaura-san,
On Monday, March 25, 2019 2:26 PM (GMT+9), Ryohei Nagaura wrote:
>Yes, I want to commit TCP_USER_TIMEOUT patches in PG12.
>Also I'd like to continue to discuss about socket_timeout after this CF.
Ok. So I'd only take a look at TCP_USER_TIMEOUT parameter for now (this
CommitFest),
Hi, kirk-san.
> From: Jamison, Kirk
> Ok. So I'd only take a look at TCP_USER_TIMEOUT parameter for now (this
> CommitFest), and maybe we could resume the discussion on socket_timeout
> in the future.
Yes, please.
> Your patch applies, however in TCP_backend_v10 patch, your documentation
> is mis
On Tuesday, March 26, 2019 2:35 PM (GMT+9), Ryohei Nagaura wrote:
>> Your patch applies, however in TCP_backend_v10 patch, your
>> documentation is missing a closing tag so it could not be
>> tested.
>> When that's fixed, it passes the make check.
>Oops! Fixed.
Ok. Confirmed the fix.
Minor nit
Hello Ryohei-san,
About the backend v11 patch.
Patch applies cleanly, though compiles with a warning.
Make check ok, although the feature is not tested.
I'm okay with exposing this parameter.
Documentation:
ISTM this is not about libpq connections but about TCP connections. There
can be non
Hello, Fabien-san.
> From: Fabien COELHO
> About the backend v11 patch.
> No space or newline before ";". Same comment about the libpq_ timeout.
Fixed.
> There is an error in the code, I think it should be < 0 to detect errors.
Yes, thanks!
> If the parameter has no effect on Windows, I do not
Hello, Fabien-san.
> From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> The default postgres configuration file should be updated to reflect the
> parameter and its default value.
I'm very sorry for not addressing your review in the last patch.
I modified TCP_backend patch (adding postgresql.conf.
Hello.
At Thu, 28 Mar 2019 01:11:23 +, "Nagaura, Ryohei"
wrote in
> Hello, Fabien-san.
>
> > From: Fabien COELHO
> > About the backend v11 patch.
> > No space or newline before ";". Same comment about the libpq_ timeout.
> Fixed.
>
> > There is an error in the code, I think it should be
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> +if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT,
> + (char *) &timeout, sizeof(timeout)) < 0 && errno !=
> ENOPROTOOPT)
> +{
> +charsebuf[256];
> +
> +appendPQExpBuffer(&conn->er
From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> > +if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT,
> > + (char *) &timeout, sizeof(timeout)) < 0 && errno !=
> > ENOPROTOOPT)
> > +{
>
Hello, Horiguchi-san.
Thank you for review.
> In TCP_backend patch:
> I think this is not mentioning backend. Why don't you copy'n paste then
> modify the description of tcp_keepalives_idle? Perhaps it needs a similar
> caveat related to Windows.
> +static const char*
> +show_tcp_user_timeout(vo
Hi, Tsunakawa-san.
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> I think that's for the case where the modules is built on an OS that
> supports TCP_USER_TIMEOUT (#ifdef TCP_USER_TIMEOUT is true), and the
> module is used on an older OS that doesn't support TCP_USER_TIMEOUT
Hi, all.
# This is a supplement of my current patches.
> From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> > In TCP_backend patch:
> > I think this is not mentioning backend. Why don't you copy'n paste
> > then modify the description of tcp_keepalives_idle? Perhaps it needs
> a
> > s
Hello,
I updated my patches.
In TCP_USER_TIMEOUT backend patch:
1) linux ver 2.6.26 -> 2.6.36
2) error for systems where doesn't support this parameter
In TCP_USER_TIMEOUT interface patch:
error for systems where doesn't support this parameter
Best regards,
-
Ryohei Nagaura
Hi Nagaura-san,
>I updated my patches.
Thanks.
>In TCP_USER_TIMEOUT backend patch:
> 1) linux ver 2.6.26 -> 2.6.36
"Linux" should be capitalized.
I confirmed that you followed Horiguchi-san's advice
to base the doc from keepalives*.
About your question:
> 3) Same as keepalives*, I used both "0
Hello, Kirk-san.
> From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com]
> >In TCP_USER_TIMEOUT backend patch:
> > 1) linux ver 2.6.26 -> 2.6.36
> "Linux" should be capitalized.
Oh, yes. I see.
> In config.sgml it uses both "zero" and "0", while in libpq.sgml it only
> uses "zero".
> Since you pa
Nagaura-san,
The client-side tcp_user_timeout patch looks good.
The server-side tcp_user_timeout patch needs fixing the following:
(1)
+ GUC_UNIT_MS | GUC_NOT_IN_SAMPLE
+ 12000, 0, INT_MAX,
GUC_NOT_IN_SAMPLE should be removed because the parameter appears in
Hello,
In the last client-side tcp user timeout patch:
+ appendPQExpBuffer(&conn->errorMessage,
+
libpq_gettext("setsockopt(TCP_USER_TIMEOUT) not supported: %s\n"),
+ SOCK_STRERROR(SOCK_ERRNO,
sebuf
Nagaura-san,
The socket_timeout patch needs the following fixes. Now that others have
already tested these patches successfully, they appear committable to me.
(1)
+ else
+ goto iiv_error;
...
+
+iiv_error:
+ conn->status = CONNECTION_BAD;
+ prin
Hi,
>The socket_timeout patch needs the following fixes. Now that others have
>already tested these patches >successfully, they appear committable to me.
In addition, regarding socket_timeout parameter.
I referred to the doc in libpq.sgml, corrected misspellings,
and rephrased the doc a little
Hi, Tsunakawa-san, Kirk-san.
Thank you for your review.
Tsunakawa-san,
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> The client-side tcp_user_timeout patch looks good.
Thanks, but I minorly changed that patch.
It is the declaration place of sebuf[], moving to just before
Hi, Kirk-san,
> From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com]
> In addition, regarding socket_timeout parameter.
> I referred to the doc in libpq.sgml, corrected misspellings, and rephrased the
> doc a little bit as below:
You aimed consistency with connect_timeout. Didn't you?
If yes, Tha
Hi, thank you for the new version.
This compiles on Windows. (I didn't comfirmed that it works
correctly..)
# ȁ (I inserted this garbage to force my mailer to send in utf-8).
At Fri, 29 Mar 2019 06:52:41 +, "Nagaura, Ryohei"
wrote in
> Hi all.
>
> I found my mistake in backend patch.
>
Hi all.
I found that connect_timeout uses pqWaitTimed().
Socket_timeout is related to pqWait() not pqWaitTimed().
Thus, I removed connect_timeout in my socket_Timeout patch.
FYI, I summarized a use case of this parameter.
The connection is built successfully.
Suppose that the server is hit by som
101 - 200 of 240 matches
Mail list logo
