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.
> 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 reb
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 "TCP_user_t
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
Descriptio
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 latter
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
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, 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
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
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
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, 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_keepal
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
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
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, 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
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
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
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
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, 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
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
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
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
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.
>
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
Hi, kirk-san.
> From: Nagaura, Ryohei
> This is my bad. I'll remake it.
> Very sorry for the same mistake.
I remade the patches and attached in this mail.
In socket_timeout patch, I replaced "atoi" to "parse_int_param" and inserted
spaces just after some co
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
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
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. Could
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 finalized
Hi Fabien,
Would you review TCP_USER_TIMEOUT patches first please?
I want to avoid the situation that
the discussion of socket_timeout has been lengthened
and tcp_user_timeout patch is also not commit in the next CF.
On Mon, Feb 4, 2019 at 2:24 AM, Michael Paquier wrote:
> Moved to next CF per
Hi,
On Mon, Jan 28, 2019 at 10:46 PM, Konstantin Knizhnik wrote:
> Rebased version of the patch is attached.
Thank you for your quick rebase.
> This files are just output of test execution and it is not possible to expect
> lack of
> trailing spaces in output of test scripts execution.
I underst
Hi,
Although I became your reviewer, it seems to be difficult to feedback in this
CF.
I continue to review, so would you update your patch please?
Until then I review your current patch.
There is one question.
date_1.out which maybe is copy of date.out includes trailing space and gaps of
indent
Hi,
Sorry for my late.
On Tue, Dec 25, 2018 at 7:40 PM, Fabien COELHO wrote:
> 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",
Hi Iwata-san,
I used your patch for my private work, so I write my opinion and four feedback
below.
On Fri, Jan 18, 2019 at 8:19 AM, Iwata, Aya wrote:
> - Setting whether to get log or not by using connection strings or environment
> variables. It means that application source code changes is not
Hi all.
-Information-
Members of Fujitsu Japan may not be able to reply in the term below.
TERM: 29th December 2018 ~ 6th January 2019
NOTE:
Members of Fujitsu Japan are those whose mail domain is "@jp.fujitsu.com"
Best regards,
-
Ryohei Nagaura
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
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,
On Fri, Dec 21, 2018 at 5:08 PM, Tom Lane wrote:
> I don't think I buy that argument; it falls down as soon as you consider
> characters above U+. I worry that by supporting UTF16, we'd basically
> be encouraging users to write code that fails on such characters, which
> doesn't seem like
Matsumura-san, Tsunakawa-san
Thank you for reply.
Tsunakawa-san
> * What's the benefit of supporting UTF16 in host variables?
There are two benefits.
1) As byte per character is constant in UTF16 encoding, it can process strings
more efficiently than other encodings.
2) This enables C programmer
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
Hi all.
There is a demand for ECPG to support UNICODE host variables.
This topic has also appeared in thread [1].
I would like to discuss whether to support in postgres.
Do you have any opinion?
The specifications and usage described below are the same as in [1].
Requirements
1. su
Hi,
There was an invisible space, so I removed it.
I registered with 2019-01 commitfest.
Best regards,
-
Ryohei Nagaura
> -Original Message-
> From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> Sent: Thursday, December 6, 2018 2:20 PM
> To: &#
Hi, Fabien.
Thank you for your review.
And I'm very sorry to have kept you waiting so long.
About "socket_timeout"
> 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.
If you
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
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, all.
I'd like to suggest introducing two parameters to handle client-server
communication timeouts.
That is "tcp_user_timeout" and "socket_timeout" parameter.
I implemented "tcp_user_timeout" parameter
in both backend and frontend side.
This parameter enables us to
use TCP_USER_TIMEOUT opt
48 matches
Mail list logo
