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 1taXZC-002hgo-0x for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 10:02:34 +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 1taXZB-00Eqky-5P for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 10:02:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1taHwC-002GT5-SC for pgsql-general@lists.postgresql.org; Tue, 21 Jan 2025 17:21:17 +0000 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1taHwA-000lRT-15 for pgsql-general@lists.postgresql.org; Tue, 21 Jan 2025 17:21:15 +0000 Received: from phl-compute-08.internal (phl-compute-08.phl.internal [10.202.2.48]) by mailfout.stl.internal (Postfix) with ESMTP id 76F17114008D; Tue, 21 Jan 2025 12:21:13 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Tue, 21 Jan 2025 12:21:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding: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=fm2; t=1737480073; x=1737566473; bh=3KBurVnfzqy2nd2PFTk7Tjzgvwm0zisCDufO+IS/Gbs=; b= WmQx00iU0h2za1gFWcU5bcfgNab4Dt0CzniBzjamFrN60BSfy6bv19ZJbL5j4V2V xUhUQ4WAwHWjq6Emb+SlWTt513qbWratRfa/lRbe/HYNPCZirv6Fjajej+c3772c u88Gg8D/gEvVYF17Y+bhekBYb0HtqF5cSPcGkeD15hLi/ANNy0IVu5Y07kI5b9P1 QRWXmSiONCt8+I5/d0GSE8ULuNAYWZi/t0ACXlk4QDOdjTsWOibGHnYMaVAYeB0E Kwnrbru8IT+qy2tIr2NiEzb/IUCPmnp2gdbTtC5AvAh5334mWbPqKSZzi5xQ+G1J p9RSmpYc+2cQe8M+7KgXfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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-sender :x-me-sender:x-sasl-enc; s=fm3; t=1737480073; x=1737566473; bh=3 KBurVnfzqy2nd2PFTk7Tjzgvwm0zisCDufO+IS/Gbs=; b=SnbfI9ZmwR8msJNx8 ymFYHellxNBDG/CWhZwxN01zVtXJRUiMetP9c5Scsgzj/27csl8sOBQBBUfKQk4f 4yyDvpmNjUBEWCEY/jerBC9AlOb5rgKWGbx3rBKkKPK+S3TvlcnQ9KPWbNLy0cON Zsz/glC/3cRAO18opTYuDKUlBWaOvE9uQTXCPYpUSFDFYCMYU8/G4Zh43ObbBs5c V8Ib+nDllUD9IynRuftnTbU82lRusL7pjndnkkyQyuhJ6Rv1lxkqWWhpCHPQA5PV Cqcs2pPDwa4xjIBj/sJGyXbjOn0a6uCcVXUWd6DcagBFXj3nr+MXFQnhQVES6i1S 0SjvQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejvddgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfhfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeetughrihgrnhcumfhlrghvvghr uceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomheqnecuggftrfgrth htvghrnhepffelgeeifefgveduhedthfekuedtffejveegffegjeevtdehgfduieetfeeh jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg gurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhdpnhgspghrtghpthhtohep vddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheptghlihhpphgvrhgusgesghhmgi drfhhrpdhrtghpthhtohepphhgshhqlhdqghgvnhgvrhgrlheslhhishhtshdrphhoshht ghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Jan 2025 12:21:12 -0500 (EST) Message-ID: <98e01d06-480c-4d27-b880-84480d1bda78@aklaver.com> Date: Tue, 21 Jan 2025 09:21:12 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: To: Lana ABADIE , pgsql-general@lists.postgresql.org References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 1/20/25 10:10, Lana ABADIE wrote: > Hi all > I bumped into a weird case that i don't really understand...maybe > someone in this list could have a clue > We have 2 Postgres databases configured as master/slave > replica (Postgresq 12, RHEL8) > We have applications which write data into the master and applications > which reads data from the replica. > A group of applications reads data using libpq: it declares a select > statement as cursor and then there is fetch which can retrieve at most > 25k rows. Add the complete SELECT and CURSOR code. > The select statement contains a between clause with T1 and T2. T1 is > injected via input parameter but T2=floor(extract (epoch from > coalesce(pg_last_xact_replay_timestamp(),now())))-120. It is passed > directly like that in the query. What does T1 represent and how is it derived? > In other words we have something like select * from ZZ where ... and > timestamp between $T1 and floor(extract (epoch from > coalesce(pg_last_xact_replay_timestamp(),now())))-120; > when this query gets executed, from time to time it returns a truncated > number of rows.. less than if i was doing between T1 and T1... I don't understand above, add more complete definition. Example data would be nice. > T2 being an integer so either T2 rows of zero or T2>=T1 and I would expect at least #rows greater or > equal to the number of rows between T1 and T1, > Note that we are talking about  a total number of rows less than 2000. > Then when i fixed T2, in other words i do a query using between $T1 and > $T2 (where T2=floor(extract (epoch from > coalesce(pg_last_xact_replay_timestamp(),now())))-120) then there is no > issues, number of rows are retrieved correctly. > I also confirmed via metrics collection that the data is there when the > query is being performed. > I would appreciate any explanations on this behavior, and hoping i'm clear. > Thanks > Doris -- Adrian Klaver adrian.klaver@aklaver.com