Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rqFRi-00BNJp-Av for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Mar 2024 16:51:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rqFRh-0036BM-Ce for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Mar 2024 16:51:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rqFRf-0036BE-WC for pgsql-hackers@lists.postgresql.org; Fri, 29 Mar 2024 16:51:13 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rqFRV-007JxY-IJ for pgsql-hackers@lists.postgresql.org; Fri, 29 Mar 2024 16:51:11 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A83F13200A01; Fri, 29 Mar 2024 12:50:56 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Fri, 29 Mar 2024 12:50:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1711731056; x=1711817456; bh=/v6Y6hbbpB 5pgjsJhjffuK72ZFzqT2jxLXMfqUl5xmo=; b=C1rTr2wfPblkMf1H+vpjao8Npb OxQJA1YAh5Ak2TT6OZGshCfWecU3U3h635v/8Xx1EFKzG5bToyRoda4Ao5PmvLnb HZ9MImLHF6YgxaAN6rU3VmKdGu2GeTJ7r3iaWTVxxGbqPh0UY/XxzDP/iRrzPqCw RYHeSAAYOgHvpsOttu0kZE3i+t31YzfoN25c7jL2yC9fqJh6TFOra47GXNB6/sX5 sqOmLIY/PDwXiOXVhT5mKkE7Cev3NedTR67inFNS3Ffv7VtOYQ1mZ6BTuCtwdV0f OMzglWL9bS3fBrnxUtoW21QU/KJXCnCad4Kwv5eK0bHj6K3kf/F9JdETlMew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1711731056; x=1711817456; bh=/v6Y6hbbpB5pgjsJhjffuK72ZFzq T2jxLXMfqUl5xmo=; b=t5KpDSA4EtmdlbNqz2p51SSc/eE14Nr1pR/6Y7kiCSzS cC951zHZvd8Vh/WpVaY0QEVvtsW2r6KIGjDf3X1pbIRuX9PR8eNWFTvvhqEO7/MQ yg/h4/u6QZv6x7hTRYYbGhZhJl9NrQoJVNql0jVDwBWZszXCjv4pMMI+/K0maNl2 whH3KUoJQGkhOMyvOuOIu/mZ3Qxf9h/VkXFGcko89NvpTdYw/mVyWGVboTtndH4o RGcbgMufO2l+7HvCoeTQ5cDCmW0mMdxP77VFIfQricv2mHgy4+92+h8xrhy9+0k3 TzEgC8USlKs5BDedfXnYR8AiZq6RpmHLSWqIZmF4AQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddvvddgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfgfhu lhgvrhcuvfgrvhgvihhrrgdfuceovghulhgvrhesvghulhgvrhhtohdrtghomheqnecugg ftrfgrthhtvghrnhepgfffjedviedvkedviedvteduieekudeivedthffhuddvteegleet ieffkeeghfdvnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegvuhhlvghrsegv uhhlvghrthhordgtohhm X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 375D815A0092; Fri, 29 Mar 2024 12:50:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542 MIME-Version: 1.0 Message-Id: <8aec133e-5d7f-4fa1-8223-257647dd1ccd@app.fastmail.com> In-Reply-To: References: <22f122-655b3e80-3-688b3700@97587957> <4953563546cb8c8851f84c7debf723ef@postgrespro.ru> <31547e4e8c263392a768ea89a3f57833@postgrespro.ru> <5358d911a08ef2952b1e9f74062426ee@postgrespro.ru> <88449be3-93e8-4d78-a0d8-c37e4cf26850@app.fastmail.com> Date: Fri, 29 Mar 2024 13:50:33 -0300 From: "Euler Taveira" To: "Alexander Korotkov" Cc: "Thomas Munro" , "Kartyshov Ivan" , "Bharath Rupireddy" , "Peter Eisentraut" , "Amit Kapila" , "Dilip Kumar" , "Peter Smith" , pgsql-hackers@lists.postgresql.org Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed Content-Type: multipart/alternative; boundary=7db76c2d38ae4b338c3ed53169025a50 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --7db76c2d38ae4b338c3ed53169025a50 Content-Type: text/plain On Fri, Mar 29, 2024, at 9:44 AM, Alexander Korotkov wrote: > This generally makes sense, but I'm not sure about this. The > milliseconds timeout was used initially but received critics in [1]. Alexander, I see why you changed the patch. Peter suggested to use an interval but you proposed another data type: float. The advantage of the interval data type is that you don't need to carefully think about the unit, however, if you use the integer data type you have to propose one. (If that's the case, milliseconds is a good granularity for this feature.) I don't have a strong preference between integer and interval data types but I don't like the float for this case. The 2 main reasons are (a) that we treat time units (hours, minutes, seconds, ...) as integers so it seems natural for a human being to use a unit time as integer and (b) depending on the number of digits after the decimal separator you still don't have an integer in the internal unit, hence, you have to round it to integer. We already have functions that use integer (such as pg_terminate_backend) and interval (such as pg_sleep_for) and if i searched correctly it will be the first timeout argument as float. -- Euler Taveira EDB https://www.enterprisedb.com/ --7db76c2d38ae4b338c3ed53169025a50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Mar 29,= 2024, at 9:44 AM, Alexander Korotkov wrote:
This generally makes sense, but I'm not= sure about this.  The
milliseconds timeout was used = initially but received critics in [1].

Alexander, I see why you changed the patch.

<= /div>
Peter suggested to use an interval but you proposed another da= ta type:
float. The advantage of the interval data type is= that you don't need to
carefully think about the unit, ho= wever, if you use the integer data
type you have to propos= e one. (If that's the case, milliseconds is a
good granula= rity for this feature.) I don't have a strong preference
b= etween integer and interval data types but I don't like the float for
this case. The 2 main reasons are (a) that we treat time uni= ts (hours,
minutes, seconds, ...) as integers so it seems = natural for a human being
to use a unit time as integer an= d (b) depending on the number of digits
after the decimal = separator you still don't have an integer in the
internal = unit, hence, you have to round it to integer.

We already have functions that use integer (such as pg_terminate_back= end)
and interval (such as pg_sleep_for) and if i searched= correctly it will
be the first timeout argument as float.=


--
Euler Taveira
=
EDB   https://www.enterprisedb.com/
<= br>
--7db76c2d38ae4b338c3ed53169025a50--