Re: Seamless age (xid) replacement

Got it. Thank you!

On Fri, Dec 20, 2024 at 9:29 AM Achilleas Mantzios - cloud <
a(dot)mantzios(at)cloud(dot)gatewaynet(dot)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
>
>
>