Horton

Re: Should we add xid_current() or a int8->xid cast?

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Mark Dilger <hornschnorter@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2020-04-17T17:33:53Z
Lists: pgsql-hackers 
On Thu, Apr 2, 2020 at 5:13 PM Andres Freund <andres@anarazel.de> wrote:
> Given that txid_current() "always" has been a plain 64 bit integer, and
> the various txid_* functions always have returned 64 bit integers, I
> really don't think arguing for some 32bit/32bit situation now makes
> sense.

I'm not sure what the best thing to do is here, but the reality is
that there are many places where 32-bit XIDs are going to be showing
up for years to come. With the format printed as a raw 64-bit
quantity, people troubleshooting stuff are going to spend a lot of
time figuring what x%2^32 is. And I can't do that in my head. So I
think saying that the proposal does not makes sense is a gross
overstatement. It may not be what we want to do. But it definitely
would make sense.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Introduce xid8-based functions to replace txid_XXX.

  2. Add SQL type xid8 to expose FullTransactionId to users.

  3. Replace the former method of determining snapshot xmax --- to wit, calling