MIME-Version: 1.0
References: <CAJjhk3Divm6hpx395nJFdN2J_ytpFVbmOp00GWOtE7D=ppVzAA@mail.gmail.com>
 <20c3185b-ff1b-4ffe-b006-4e0ddb4e043b@cloud.gatewaynet.com>
In-Reply-To: <20c3185b-ff1b-4ffe-b006-4e0ddb4e043b@cloud.gatewaynet.com>
From: Ivan Shershnev <ivan.shershnev@jetbrains.com>
Date: Mon, 23 Dec 2024 11:00:00 +0100
Message-ID: <CAJjhk3CDzdA+8PQG-WAQ5yqWh8vw2dtEa5iDA+5Bq9VdW1587g@mail.gmail.com>
Subject: Re: Seamless age (xid) replacement
To: Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com>
Cc: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fab2ea0629ed0f6d"
Archived-At: <https://www.postgresql.org/message-id/CAJjhk3CDzdA%2B8PQG-WAQ5yqWh8vw2dtEa5iDA%2B5Bq9VdW1587g%40mail.gmail.com>
Precedence: bulk

--000000000000fab2ea0629ed0f6d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Got it. Thank you!

On Fri, Dec 20, 2024 at 9:29=E2=80=AFAM Achilleas Mantzios - cloud <
a.mantzios@cloud.gatewaynet.com> wrote:

>
> On 12/4/24 17:51, Ivan Shershnev wrote:
> > Hello!
> >
> > I need to use the 'age (xid)' function, but I have noticed that it is
> > deprecated without a clear alternative. I know that xid is also kinda
> > deprecated, so it makes sense not to use it. I can get xid8 from
> > 'pg_current_xact_id()', which replaced 'txid_current()', but cannot
> > use it right away with 'age'.
> >
> > I can cast xid8 that I've got to xid and pass to 'age', but 1) I have
> > no idea if it's the right way, i.e. it's promised to work or will work
> > anyway by accident, 2) 'age' is anyway deprecated.
> >
> > I can re-implement 'age' by myself. It's (mostly) a subtraction after
> > all. But it would mean that I inline implementation in place of "api"
> > function call which is not always a great idea.
>
> If I am not gravely mistaken, transaction id is still (as of pgsql 17)
> kept in a 32 bit int. You can checkout the source, in the docs
> (https://www.postgresql.org/docs/current/routine-vacuuming.html) it
> still says we are limited to the 32 bit int. Otherwise, all of a sudden
> all our VACUUM troubles would have gone away, and we would see ads and
> banners and flyers all over !!, so no, it is still 32 bit.
>
> So, you can just cast with confidence.
>
> Regarding pgsql system functions, some arguments, return values have
> turned to xid8 others remain xid, so currently this is a mix. I guess
> the goal is to go full 64 bit some time in some future version.
>
> >
> > Could anyone advise, please?
> >
> > Kind regards,
> > Ivan
>
>
>

--000000000000fab2ea0629ed0f6d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Got it. Thank you!<br></div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 20=
, 2024 at 9:29=E2=80=AFAM Achilleas Mantzios - cloud &lt;<a href=3D"mailto:=
a.mantzios@cloud.gatewaynet.com">a.mantzios@cloud.gatewaynet.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 12/4/24 17:51, Ivan Shershnev wrote:<br>
&gt; Hello!<br>
&gt;<br>
&gt; I need to use the &#39;age (xid)&#39; function, but I have noticed tha=
t it is <br>
&gt; deprecated without a clear alternative. I know that xid is also kinda =
<br>
&gt; deprecated, so it makes sense not to use it. I can get xid8 from <br>
&gt; &#39;pg_current_xact_id()&#39;, which replaced &#39;txid_current()&#39=
;, but cannot <br>
&gt; use it right away with &#39;age&#39;.<br>
&gt;<br>
&gt; I can cast xid8 that I&#39;ve got to xid and pass to &#39;age&#39;, bu=
t 1) I have <br>
&gt; no idea if it&#39;s the right way, i.e. it&#39;s promised to work or w=
ill work <br>
&gt; anyway by accident, 2) &#39;age&#39; is anyway deprecated.<br>
&gt;<br>
&gt; I can re-implement &#39;age&#39; by myself. It&#39;s (mostly) a subtra=
ction after <br>
&gt; all. But it would mean that I inline implementation in place of &quot;=
api&quot; <br>
&gt; function call which is not always a great idea.<br>
<br>
If I am not gravely mistaken, transaction id is still (as of pgsql 17) <br>
kept in a 32 bit int. You can checkout the source, in the docs <br>
(<a href=3D"https://www.postgresql.org/docs/current/routine-vacuuming.html"=
 rel=3D"noreferrer" target=3D"_blank">https://www.postgresql.org/docs/curre=
nt/routine-vacuuming.html</a>) it <br>
still says we are limited to the 32 bit int. Otherwise, all of a sudden <br=
>
all our VACUUM troubles would have gone away, and we would see ads and <br>
banners and flyers all over !!, so no, it is still 32 bit.<br>
<br>
So, you can just cast with confidence.<br>
<br>
Regarding pgsql system functions, some arguments, return values have <br>
turned to xid8 others remain xid, so currently this is a mix. I guess <br>
the goal is to go full 64 bit some time in some future version.<br>
<br>
&gt;<br>
&gt; Could anyone advise, please?<br>
&gt;<br>
&gt; Kind regards,<br>
&gt; Ivan<br>
<br>
<br>
</blockquote></div>

--000000000000fab2ea0629ed0f6d--