Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>
Cc: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Japin Li <japinli(at)hotmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Ilya Anfimov <ilan(at)tzirechnoy(dot)com>
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Date: 2022-03-18 23:20:49
Message-ID: 20220318232049.zqtuhu3zxchsbeya@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-03-18 18:14:52 +0300, Maxim Orlov wrote:
> Subject: [PATCH v22 3/6] Use 64-bit pages in SLRU
>
> This is one step toward 64-bit XIDs.

I think this should explain in more detail why this move is done. Neither the
commit message nor the rest of the thread does so afaics. It's not too hard to
infer, but the central reason behind a patch shouldn't need to be inferred.

> -static bool CLOGPagePrecedes(int page1, int page2);
> +static bool CLOGPagePrecedes(int64 page1, int64 page2);

I think all of these are actually unsigned integers. If all of this stuff gets
touched, perhaps worth moving to uint64 instead?

https://www.postgresql.org/message-id/20220318231430.m5g56yk4ztlz2man%40alap3.anarazel.de

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-18 23:26:13 Re: Add 64-bit XIDs into PostgreSQL 15
Previous Message Andres Freund 2022-03-18 23:14:30 Re: Fix unsigned output for signed values in SLRU error reporting