From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | 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:01:09 |
Message-ID: | 20200402180109.ihwozk3h7gcopw7g@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-04-02 14:33:18 -0300, Alvaro Herrera wrote:
> On 2020-Apr-02, Thomas Munro wrote:
>
> > On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > > * updated OIDs to avoid collisions
> > > * added btequalimage to btree/xid8_ops
> >
> > Here's the version I'm planning to commit tomorrow, if no one objects. Changes:
> >
> > * txid.c renamed to xid8funcs.c
> > * remaining traces of "txid" replaced various internal identifiers
> > * s/backwards compatible/backward compatible/ in funcs.sgml (en_GB -> en_US)
>
> 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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David Zhang | 2020-04-02 18:05:17 | Re: Allow continuations in "pg_hba.conf" files |
Previous Message | Andres Freund | 2020-04-02 17:50:28 | Re: Proposal: Expose oldest xmin as SQL function for monitoring |