| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, 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-17 18:07:07 |
| Message-ID: | CA+TgmoYDNXSQj-nEyNgH3WmD0gNepCVqgbrgjrDt2fxLzAVUsQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 17, 2020 at 1:45 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> You seem to be entirely disregarding my actual point, namely that
> txid_current(), as well as some other txid_* functions, have returned
> 64bit xids for many many years. txid_current() is the only function to
> get the current xid in a reasonable way. I don't understand how a
> proposal to add a 32/32 bit representation *in addition* to the existing
> 32 and 64bit representations is going to improve the situation. Nor do I
> see changing txid_current()'s return format as something we're going to
> go for.
>
> I did not argue against a function to turn 64bit xids into epoch/32bit
> xid or such.
I thought we were talking about how the new xid8 type ought to behave.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2020-04-17 18:18:17 | Re: Additional Chapter for Tutorial |
| Previous Message | Jürgen Purtz | 2020-04-17 17:56:08 | Additional Chapter for Tutorial |