Re: uuidv7 improperly accepts dates before 1970-01-01

From: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
Date: 2026-05-28 01:00:50
Message-ID: CA+fm-ROd4cNKM524n6EdgtZ9xOzOHJDNv8J_9Mvr2+2t1qWSDw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hello Masahiko,

On Wed, May 27, 2026 at 7:02 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> I guess it would be safer to raise an error in such cases rather than
> silently allowing wraparound. Otherwise, users might only realize that
> their UUIDv7 values are no longer sortable years down the road, which
> would be disastrous. Moreover, raising an error would be consistent
> with how PostgreSQL natively handles timestamp + interval overflows.
>

+1. I ran into the same issue while testing, specifically,
uuidv7('infinity'::interval) overflows int64 during the epoch
conversion and produces a UUID with an incorrect timestamp.
There's no valid use case for infinity as a shift offset.

I have a small patch that adds a TIMESTAMP_NOT_FINITE check after
timestamptz_pl_interval(), which catches both infinity and
-infinity. Happy to extend it to also cover the 48-bit upper/lower
bound checks if we agree on the direction.

Thanks,
Baji Shaik

Attachment Content-Type Size
0001-Fix-uuidv7-with-infinite-interval-causing-integer-ov.patch application/octet-stream 2.9 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2026-05-28 01:12:09 Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8
Previous Message Masahiko Sawada 2026-05-28 00:02:09 Re: uuidv7 improperly accepts dates before 1970-01-01

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-05-28 01:01:01 Re: Fix safe_wal_size for slots without restart_lsn
Previous Message Chao Li 2026-05-28 00:39:48 Re: Set notice receiver before libpq connection startup