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 1udrey-001aKl-Nx for pgsql-bugs@arkaria.postgresql.org; Mon, 21 Jul 2025 14:38:33 +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 1udrex-001Nbe-Or for pgsql-bugs@arkaria.postgresql.org; Mon, 21 Jul 2025 14:38:32 +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 1udrex-001NbV-Gc for pgsql-bugs@lists.postgresql.org; Mon, 21 Jul 2025 14:38:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1udreu-0003Sb-19 for pgsql-bugs@lists.postgresql.org; Mon, 21 Jul 2025 14:38:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 56LEcQ88439889; Mon, 21 Jul 2025 10:38:26 -0400 From: Tom Lane To: Nathan Bossart cc: gorcom2012@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary() In-reply-to: References: <18993-fd78c35834306695@postgresql.org> Comments: In-reply-to Nathan Bossart message dated "Mon, 21 Jul 2025 09:29:32 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <439887.1753108706.1@sss.pgh.pa.us> Date: Mon, 21 Jul 2025 10:38:26 -0400 Message-ID: <439888.1753108706@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > On Mon, Jul 21, 2025 at 12:29:16PM +0000, PG Bug reporting form wrote: >> This is unreachable because icycles is assigned directly from tcycles. > I see the following upstream commit and discussion related to this: Yeah. The short answer here is that this code is meant to deal with cases where time_t is wider than int[64]. Perhaps we're uninterested in dealing with that case ... but we also don't want to deviate too far from the upstream tzdb code. So I'm inclined to leave it alone. As the function's comment mentions, * A function result of -1 indicates failure (this case does not actually * occur in our current implementation). so presumably both "return -1" lines are unreachable. regards, tom lane