Обсуждение: BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

Поиск
Список
Период
Сортировка

BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      18993
Logged by:          Eugeny Goryachev
Email address:      gorcom2012@gmail.com
PostgreSQL version: 17.4
Operating system:   Ubuntu
Description:

Hello,
In pg_next_dst_boundary() (src/timezone/localtime.c), the following
condition can never be true:
```
if (tcycles - icycles >= 1 || icycles - tcycles >= 1)
    return -1;
```
This is unreachable because icycles is assigned directly from tcycles.

Suggested fix:
Remove this condition entirely

The change is safe as it only removes dead code. All timezone transition
cases are already properly handled by other paths.

Best regards, Eugeny Goryachev


Re: BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

От
Nathan Bossart
Дата:
On Mon, Jul 21, 2025 at 12:29:16PM +0000, PG Bug reporting form wrote:
> In pg_next_dst_boundary() (src/timezone/localtime.c), the following
> condition can never be true:
> ```
> if (tcycles - icycles >= 1 || icycles - tcycles >= 1)
>     return -1;
> ```
> This is unreachable because icycles is assigned directly from tcycles.

I see the following upstream commit and discussion related to this:

    https://github.com/eggert/tz/commit/b0bf6d8
    https://mm.icann.org/pipermail/tz/2013-August/019493.html

-- 
nathan



Re: BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

От
Tom Lane
Дата:
Nathan Bossart <nathandbossart@gmail.com> 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