Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tOYOC-00782I-Go for pgsql-general@arkaria.postgresql.org; Fri, 20 Dec 2024 08:29:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tOYOA-007JvE-VL for pgsql-general@arkaria.postgresql.org; Fri, 20 Dec 2024 08:29:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tOYOA-007Jv6-KW for pgsql-general@lists.postgresql.org; Fri, 20 Dec 2024 08:29:38 +0000 Received: from cloud.gatewaynet.com ([185.90.37.94]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tOYO7-000WN0-BY for pgsql-general@lists.postgresql.org; Fri, 20 Dec 2024 08:29:37 +0000 Message-ID: <20c3185b-ff1b-4ffe-b006-4e0ddb4e043b@cloud.gatewaynet.com> Date: Fri, 20 Dec 2024 10:29:31 +0200 MIME-Version: 1.0 Subject: Re: Seamless age (xid) replacement To: pgsql-general@lists.postgresql.org References: Content-Language: en-US From: Achilleas Mantzios - cloud In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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