From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Mark Dilger <hornschnorter(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Should we add xid_current() or a int8->xid cast? |
Date: | 2020-04-02 18:47:32 |
Message-ID: | B7D88DC1-DDB5-4220-A118-7912C26CBD29@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Apr 2, 2020, at 11:01 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>>
>> Hmm, for some reason I had it in my head that we would make these use an
>> "epoch/val" output format rather than raw uint64 values.
>
> Why would we do that? IMO the goal should be to reduce awareness of the
> 32bitness of normal xids from as many places as possible, and treat them
> as an internal space optimization.
I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs as an internal implementation and storage detail only, but we still have user facing views that don't treat it that way. pg_stat_get_activity still returns backend_xid and backend_xmin as 32-bit, not 64-bit. Should this function change to be consistent? I'm curious what the user experience will be during the transitional period where some user facing xids are 64 bit and others (perhaps the same xids but viewed elsewhere) will be 32 bit. That might make it difficult for users to match them up.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-04-02 18:51:59 | Re: control max length of parameter values logged |
Previous Message | Peter Geoghegan | 2020-04-02 18:28:06 | Re: snapshot too old issues, first around wraparound and then more. |