Use pg_current_xact_id() instead of deprecated txid_current()

On 2026-02-08, Shinya Kato wrote:

Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.

I think it may be better to add some operators, or was there a rationale for these not being there?

--
Álvaro Herrera

On Sun, Feb 8, 2026 at 7:50 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:

On 2026-02-08, Shinya Kato wrote:

Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.

I think it may be better to add some operators, or was there a rationale for these not being there?

Thank you for your comment!
I don't have a strong opinion on this, but according to [0]/messages/by-id/CA+hUKGL0TKUm3g8dywe6zVeSJLkaRYet1CgXMsB+F3bXJRJHFA@mail.gmail.com, xid8 was
intentionally designed not to support arithmetic.

[0]: /messages/by-id/CA+hUKGL0TKUm3g8dywe6zVeSJLkaRYet1CgXMsB+F3bXJRJHFA@mail.gmail.com

--
Best regards,
Shinya Kato
NTT OSS Center

=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes:

On 2026-02-08, Shinya Kato wrote:

Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.

I think it may be better to add some operators, or was there a rationale for these not being there?

I'm fairly concerned about overloading the arithmetic operators with
unsigned versions. The reason we never invented SQL-level uint8 and
such is fear of getting a lot of "ambiguous operator" errors. Now,
if we are careful not to create implicit casts between xid[8] and
any ordinary type, maybe it'd be okay to invent xid+int, xid8-int,
and a few more.

As things stand, I don't find the proposed patch to be an improvement.

regards, tom lane

On Mon, Feb 9, 2026 at 1:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes:

On 2026-02-08, Shinya Kato wrote:

Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.

I think it may be better to add some operators, or was there a rationale for these not being there?

I'm fairly concerned about overloading the arithmetic operators with
unsigned versions. The reason we never invented SQL-level uint8 and
such is fear of getting a lot of "ambiguous operator" errors. Now,
if we are careful not to create implicit casts between xid[8] and
any ordinary type, maybe it'd be okay to invent xid+int, xid8-int,
and a few more.

Got it. I’ll give it a try, thanks.

As things stand, I don't find the proposed patch to be an improvement.

I agree that casting xid8 to bigint was not the right approach.
However, I still believe it's important to move away from using
deprecated functions.

--
Best regards,
Shinya Kato
NTT OSS Center

On Mon, Feb 9, 2026 at 9:07 PM Shinya Kato <shinya11.kato@gmail.com> wrote:

On Mon, Feb 9, 2026 at 1:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes:

On 2026-02-08, Shinya Kato wrote:

Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.

I think it may be better to add some operators, or was there a rationale for these not being there?

I'm fairly concerned about overloading the arithmetic operators with
unsigned versions. The reason we never invented SQL-level uint8 and
such is fear of getting a lot of "ambiguous operator" errors. Now,
if we are careful not to create implicit casts between xid[8] and
any ordinary type, maybe it'd be okay to invent xid+int, xid8-int,
and a few more.

Got it. I’ll give it a try, thanks.

I have added the + and - operators for the xid8 type in the v2-0001
patch. This allows for direct arithmetic and eliminates the need for
casting through text and bigint. Specifically, I implemented:

xid8 + int8 -> xid8
int8 + xid8 -> xid8
xid8 - int8 -> xid8
xid8 - xid8 -> int8

Additionally, the v2-0002 patch removes the existing ::text::bigint
casts where they are no longer necessary.

--
Best regards,
Shinya Kato
NTT OSS Center

Rebased the patches.

--
Best regards,
Shinya Kato
NTT OSS Center

On Thu, May 14, 2026 at 9:31 PM Shinya Kato <shinya11.kato@gmail.com> wrote:

Rebased the patches.

Rebased the patches, again.

--
Best regards,
Shinya Kato
NTT OSS Center

Hi Shinya,

Thanks for the patches. I read v4-0001 and have a few small observations
from going through the arithmetic functions. I tested the suggestions
below locally on top of v4 — they pass the existing xid regression tests
and produce identical output on the boundary cases listed in section 3.

1. xid8pl / xid8mi could reuse the helpers in common/int.h
----------------------------------------------------
xid8pl currently rolls its own overflow detection on a mixed-sign
addition:

result = val + (uint64) delta;
if ((delta > 0 && result < val) || (delta < 0 && result > val))
ereport(ERROR, ...);

This is correct, but it's the only place in the tree that takes this
approach, and the (uint64)-of-a-signed-value plus sign-aware compare
takes a moment to convince oneself of. common/int.h already provides
pg_add_u64_overflow / pg_sub_u64_overflow, plus pg_abs_s64 which returns
uint64 and explicitly handles INT64_MIN, so xid8pl could be written as:

uint64 abs_delta = pg_abs_s64(delta);
bool overflow;

if (delta >= 0)
overflow = pg_add_u64_overflow(val, abs_delta, &result);
else
overflow = pg_sub_u64_overflow(val, abs_delta, &result);

if (overflow)
ereport(ERROR, ...);

And xid8mi symmetrically (add/sub swapped):

uint64 abs_delta = pg_abs_s64(delta);
bool overflow;

if (delta >= 0)
overflow = pg_sub_u64_overflow(val, abs_delta, &result);
else
overflow = pg_add_u64_overflow(val, abs_delta, &result);

if (overflow)
ereport(ERROR, ...);

This keeps the code inside the standard PG overflow-check idiom, and as
a side effect handles a delta of INT64_MIN cleanly (pg_abs_s64 returns
2^63 in that case without invoking UB).

2. INT64_MIN boundary in xid8_mi_xid8
----------------------------------------------------
In the val1 < val2 branch:

if (val2 - val1 > (uint64) PG_INT64_MAX + 1)
ereport(ERROR, ...);
PG_RETURN_INT64(-((int64) (val2 - val1)));

The bound permits val2 - val1 == 2^63 (e.g. '0'::xid8 -
'9223372036854775808'::xid8). When val2 - val1 == 2^63, the cast
(int64)(val2 - val1) is implementation-defined (the value doesn't fit in
int64), and -INT64_MIN is signed overflow (UB). In practice on
two's-complement targets the answer comes out as INT64_MIN, which is the
correct value, but it relies on UB.

Pulling out the boundary explicitly keeps the same observable behavior
without the UB:

uint64 diff = val2 - val1;

if (diff > (uint64) PG_INT64_MAX + 1)
ereport(ERROR, ...);
/* diff == 2^63 maps to INT64_MIN */
if (diff > (uint64) PG_INT64_MAX)
PG_RETURN_INT64(PG_INT64_MIN);
PG_RETURN_INT64(-(int64) diff);

3. Test coverage
----------------------------------------------------
The regression tests in xid.sql exercise the positive overflow side
nicely but miss a few boundaries on the negative side:

-- xid8 - xid8 at the INT64_MIN boundary (#2 above)
select '0'::xid8 - '9223372036854775808'::xid8;

-- xid8 + int8 / xid8 - int8 with INT64_MAX / INT64_MIN deltas
select '0'::xid8 + 9223372036854775807::bigint;
select '0'::xid8 - (-9223372036854775807 - 1)::bigint;
select '9223372036854775807'::xid8 - (-9223372036854775807 - 1)::bigint;

It would be good to pin those down in the expected output.

4. Documentation
----------------------------------------------------
v4-0001 adds four user-visible operators but doesn't touch doc/src/sgml/.
pg_lsn's arithmetic operators are documented in datatype.sgml around the
"pg_lsn Type" section -- it would be nice for the new xid8 operators to
get analogous coverage in the nearby xid8 paragraph.

As a separate observation (probably better as a follow-up thread rather
than expanding the scope of this one): xid8 currently has only hash and
btree opclasses, no BRIN. Since xid8 is strictly monotonic and never
wraps, BRIN minmax looks like a natural fit -- I'll raise that
separately if there's interest.

Regards,
Teletele

On Thu, May 28, 2026 at 2:08 AM lin teletele <teletele.lin@gmail.com> wrote:

Hi Shinya,

Thanks for the patches. I read v4-0001 and have a few small observations
from going through the arithmetic functions. I tested the suggestions
below locally on top of v4 — they pass the existing xid regression tests
and produce identical output on the boundary cases listed in section 3.

Thanks for the review!

1. xid8pl / xid8mi could reuse the helpers in common/int.h
----------------------------------------------------
xid8pl currently rolls its own overflow detection on a mixed-sign
addition:

result = val + (uint64) delta;
if ((delta > 0 && result < val) || (delta < 0 && result > val))
ereport(ERROR, ...);

This is correct, but it's the only place in the tree that takes this
approach, and the (uint64)-of-a-signed-value plus sign-aware compare
takes a moment to convince oneself of. common/int.h already provides
pg_add_u64_overflow / pg_sub_u64_overflow, plus pg_abs_s64 which returns
uint64 and explicitly handles INT64_MIN, so xid8pl could be written as:

uint64 abs_delta = pg_abs_s64(delta);
bool overflow;

if (delta >= 0)
overflow = pg_add_u64_overflow(val, abs_delta, &result);
else
overflow = pg_sub_u64_overflow(val, abs_delta, &result);

if (overflow)
ereport(ERROR, ...);

And xid8mi symmetrically (add/sub swapped):

uint64 abs_delta = pg_abs_s64(delta);
bool overflow;

if (delta >= 0)
overflow = pg_sub_u64_overflow(val, abs_delta, &result);
else
overflow = pg_add_u64_overflow(val, abs_delta, &result);

if (overflow)
ereport(ERROR, ...);

This keeps the code inside the standard PG overflow-check idiom, and as
a side effect handles a delta of INT64_MIN cleanly (pg_abs_s64 returns
2^63 in that case without invoking UB).

Agreed. v5 rewrites xid8pl and xid8mi along the lines you suggested.

2. INT64_MIN boundary in xid8_mi_xid8
----------------------------------------------------
In the val1 < val2 branch:

if (val2 - val1 > (uint64) PG_INT64_MAX + 1)
ereport(ERROR, ...);
PG_RETURN_INT64(-((int64) (val2 - val1)));

The bound permits val2 - val1 == 2^63 (e.g. '0'::xid8 -
'9223372036854775808'::xid8). When val2 - val1 == 2^63, the cast
(int64)(val2 - val1) is implementation-defined (the value doesn't fit in
int64), and -INT64_MIN is signed overflow (UB). In practice on
two's-complement targets the answer comes out as INT64_MIN, which is the
correct value, but it relies on UB.

Pulling out the boundary explicitly keeps the same observable behavior
without the UB:

uint64 diff = val2 - val1;

if (diff > (uint64) PG_INT64_MAX + 1)
ereport(ERROR, ...);
/* diff == 2^63 maps to INT64_MIN */
if (diff > (uint64) PG_INT64_MAX)
PG_RETURN_INT64(PG_INT64_MIN);
PG_RETURN_INT64(-(int64) diff);

Fixed.

3. Test coverage
----------------------------------------------------
The regression tests in xid.sql exercise the positive overflow side
nicely but miss a few boundaries on the negative side:

-- xid8 - xid8 at the INT64_MIN boundary (#2 above)
select '0'::xid8 - '9223372036854775808'::xid8;

-- xid8 + int8 / xid8 - int8 with INT64_MAX / INT64_MIN deltas
select '0'::xid8 + 9223372036854775807::bigint;
select '0'::xid8 - (-9223372036854775807 - 1)::bigint;
select '9223372036854775807'::xid8 - (-9223372036854775807 - 1)::bigint;

It would be good to pin those down in the expected output.

Added in v5. I also threw in '0'::xid8 - '9223372036854775809'::xid8.

4. Documentation
----------------------------------------------------
v4-0001 adds four user-visible operators but doesn't touch doc/src/sgml/.
pg_lsn's arithmetic operators are documented in datatype.sgml around the
"pg_lsn Type" section -- it would be nice for the new xid8 operators to
get analogous coverage in the nearby xid8 paragraph.

Done in v5. A paragraph modeled on the pg_lsn one is now placed
immediately after the existing xid8 paragraph in datatype.sgml.

As a separate observation (probably better as a follow-up thread rather
than expanding the scope of this one): xid8 currently has only hash and
btree opclasses, no BRIN. Since xid8 is strictly monotonic and never
wraps, BRIN minmax looks like a natural fit -- I'll raise that
separately if there's interest.

Agreed it's a natural fit, and it deserves its own thread rather than
expanding this one.

0001 carries all of the changes above. 0002 is unchanged from v4 apart
from the rebase.

--
Best regards,
Shinya Kato
NTT OSS Center

Hi Shinya,

Thanks for the updated v5. Looked at v5 — the arithmetic is correct,
and the tests cover the edges.
One nit: in-development patches usually pick OIDs in the 8000-9999
range per bki.sgml, but it's not a big deal — the committer renumbers
OIDs anyway.

LGTM otherwise.

On Tue, Jun 2, 2026 at 4:14 PM lin teletele <teletele.lin@gmail.com> wrote:

Hi Shinya,

Thanks for the updated v5. Looked at v5 — the arithmetic is correct,
and the tests cover the edges.

Thanks for the review!

One nit: in-development patches usually pick OIDs in the 8000-9999
range per bki.sgml, but it's not a big deal — the committer renumbers
OIDs anyway.

I didn't know that, so I've fixed in v6.

--
Best regards,
Shinya Kato
NTT OSS Center

On Tue, Jun 2, 2026 at 7:21 PM Shinya Kato <shinya11.kato@gmail.com> wrote:

I didn't know that, so I've fixed in v6.

v6 looks good — OIDs are in the 8000-9999 range now, and nothing
else changed. The arithmetic and tests are unchanged from v5.

Marking this Ready for Committer. Thanks for the patch!

Hi all,

On Tue, Jun 9, 2026 at 3:01 PM Shinya Kato <shinya11.kato@gmail.com> wrote:

On Tue, Jun 2, 2026 at 4:14 PM lin teletele <teletele.lin@gmail.com> wrote:

Hi Shinya,

Thanks for the updated v5. Looked at v5 — the arithmetic is correct,
and the tests cover the edges.

Thanks for the review!

One nit: in-development patches usually pick OIDs in the 8000-9999
range per bki.sgml, but it's not a big deal — the committer renumbers
OIDs anyway.

I didn't know that, so I've fixed in v6.

I have reviewed the patches and tested the newly added xid8 arithmetic
operators along with the changes replacing txid_current() with
pg_current_xact_id() and have successfully verified the following
cases like Basic addition and subtraction using xid8 and int8, Reverse
addition (int8 + xid8) behavior, Arithmetic with zero and negative
values, xid8 - xid8 operations for normal cases, Boundary conditions
involving INT64_MAX and INT64_MIN, Overflow and underflow handling for
xid8 arithmetic, Maximum and minimum supported xid8 values, Type
mismatch cases with unsupported operand types and Commutative behavior
of the newly added addition operators. I also verified the INT64_MIN
boundary case discussed in the thread using a valid bigint literal
representation, and the arithmetic behaved as expected. Cases where
the result exceeded the bigint range correctly reported as "bigint out
of range", while xid8 overflow and underflow conditions correctly
produced "xid8 out of range errors". Based on my testing, the new
arithmetic operators are functioning as expected, the boundary cases
are handled correctly, and I did not observe any functional issues
with the patch. The patch looks good to me too.

Regards,
Solai