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.98.2) (envelope-from ) id 1xD75n-00000000K4u-0Ezi for pgsql-bugs@arkaria.postgresql.org; Sat, 03 Oct 2026 21:16:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xD75m-000000039U9-0Qbu for pgsql-bugs@arkaria.postgresql.org; Sat, 03 Oct 2026 21:16:26 +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.98.2) (envelope-from ) id 1xClsI-00000001Ty2-0BAY for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:37:06 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xClsG-000000004qM-2Ic9 for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:37:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=K4kbV1UxDeTO0RBbeH7wvSUw7ve4xENFUYQhoDEWhJY=; b=sG+/sL5xOalmPBuFxzBiDVuuQW nVEve6iE2NwN1pR8PWOUZRjQrHfqoEPRxREHAnzP9pUvv8aijOf0cWm0nIdTHu03TIYS1zaVjoegd BPjhemaPj1um6t5IFiAYXopc6Fe6BjsMDJ65Fa3/t7j4gjfbjf+I4z0YWvem58+htfd/vW/pni5cr y/J4opFYvNf4gD+w/+AvvquH64wHWK65l0jOXw3+gH/t8FN00wV2LNWSTmXg9TvWq8yQ+U7xFuBfj gWSbAZ7wpVrypDauNoX7mBkxsxye0rR21ZNPhc76AfYwtJYoypfrNSsAAQhuLAwp2yM6Bh/IpF8z1 0Le4Q0sg==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xClsG-00000000JAY-0plj for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:37:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xClsF-00000000sbV-0EX4 for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:37:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19738: `uuidv7(interval)` rejects sub-millisecond timestamps within the final 48-bit millisecond To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: theshallow27@gmail.com Reply-To: theshallow27@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 02 Oct 2026 22:36:49 +0000 Message-ID: <19738-659d03aaa312f3b8@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19738 Logged by: Shallow Email address: theshallow27@gmail.com PostgreSQL version: 18.6 Operating system: Linux Description: =20 UUIDv7 stores a 48-bit Unix-millisecond timestamp, and PostgreSQL's documentation says its timestamp also includes sub-millisecond precision. A shifted timestamp 250 microseconds into the final representable millisecond is rejected as out of range, although its millisecond field is still the maximum valid value. **Reproduction:** ```sql SELECT uuidv7( (timestamptz '1970-01-01 UTC' + interval '281474976710655 milliseconds' + interval '250 microseconds') - clock_timestamp() ); ``` **Actual result:** SQLSTATE `22008`, `timestamp out of range for UUID version 7`. **Expected result:** Generate a UUIDv7 whose 48-bit millisecond timestamp is `2^48 - 1`, preserving the permitted sub-millisecond component.