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,
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
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
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 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
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
Hello.
> From: Jamison, Kirk
> As for socket_timeout, I agree that this can be discussed further.
Yes, probably.
> 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
Hi again,
Since Nagaura-san seems to have addressed the additional comments on
tcp user timeout patches, I still retain the status for the patch set as
ready for committer.
As for socket_timeout, I agree that this can be discussed further.
>Fabien Coelho wrote:
>> I still think that this
Hello, Fabien-san.
> From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> I have further remarks after Kirk-san extensive review on these patches.
Yes, I'm welcome.
Thank you very much for your review.
> * About TCP interface v18.
> For homogeneity with the surrounding cases, ISTM that
Hi all.
I found my mistake in backend patch.
I modified from
+ port->keepalives_count = count;
to
+ port->tcp_user_timeout = timeout;
in line 113.
Sorry for mistake like this again and again...
Best regards,
-
Ryohei Nagaura
socket_timeout_v12.patch
Hi Nagaura-san,
Thank you for the updated patches.
It became a long thread now, but it's okay, you've done a good amount of work.
There are 3 patches in total: 2 for tcp_user_timeout parameter, 1 for
socket_timeout.
A. TCP_USER_TIMEOUT
Since I've been following the updates, I compiled a
Hi Horiguchi-san,
Thank you so much for your review!
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> Hmm. "forcefully" means powerful or assertive, in Japanese "力強く
> " or "強硬に". "forcibly" means acoomplished through force, in Japanesee "
> 無理やり" or "強引に". Actually the
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
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, 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,
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,
>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
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;
+
Hello,
In the last client-side tcp user timeout patch:
+ appendPQExpBuffer(>errorMessage,
+
libpq_gettext("setsockopt(TCP_USER_TIMEOUT) not supported: %s\n"),
+ SOCK_STRERROR(SOCK_ERRNO,
sebuf,
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
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
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
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
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
> >
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
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*
>
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 *) , sizeof(timeout)) < 0 && errno !=
> > ENOPROTOOPT)
> > +{
> > +
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> +if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT,
> + (char *) , sizeof(timeout)) < 0 && errno !=
> ENOPROTOOPT)
> +{
> +charsebuf[256];
> +
> +appendPQExpBuffer(>errorMessage,
>
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
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
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 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
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
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
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
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
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
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
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
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
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
> 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
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
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]
> 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
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
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
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
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
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
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
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
>
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: 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
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
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,
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
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
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
>
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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,
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
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
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.
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
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
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
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 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
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
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
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
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
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
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
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
>
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
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
Hello, all.
> 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 and
On Thursday, February 21, 2019 2:56 PM (GMT+9), Tsunakawa, Takayuki wrote:
>> 1) tcp_user_timeout parameter
>> I think this can be "committed" separately when it's finalized.
> Do you mean you've reviewed and tested the patch by simulating a
> communication failure in the way Nagaura-san
From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> > Maybe. Could you suggest good description?
> Clients wait until the socket become readable when they try to get results
> of their query.
> If the socket state get readable, clients read results.
> (See
Hi, Tsunakawa-san
Thank you for your comments.
On Wed, Feb 20, 2019 at 5:56 PM, Tsunakawa, Takayuki wrote:
> > Perhaps you could also clarify a bit more through documentation on how
> > socket_timeout handles the timeout differently from statement_timeout
> > and tcp_user_timeout.
> Maybe.
From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> BTW, tcp_user_timeout parameter of servers and clients have same name in
> my current implementation.
> I think it would be better different name rather than same name.
> I'll name them as the following a) or b):
> a)
Hi, Kirk-san.
Thank you for summarizing this thread.
On Tue, Feb 19, 2019 at 6:05 PM, Jamison, Kirk wrote:
> 1) tcp_user_timeout parameter
> As for user_timeout param, there seems to be a common agreement with regards
> to its need.
> I think this can be "committed" separately when it's
From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com]
> 1) tcp_user_timeout parameter
> I think this can be "committed" separately when it's finalized.
Do you mean you've reviewed and tested the patch by simulating a communication
failure in the way Nagaura-san suggested?
> 2)
Hi,
I tried to re-read the whole thread.
Based from what I read, there are two proposed timeout parameters,
which I think can be discussed and commited separately:
(1) tcp_user_timeout
(2) tcp_socket_timeout (or suggested client_statement_timeout,
1 - 100 of 117 matches
Mail list logo
