Date: Wed, 26 Jun 2024 11:58:44 -0700
From: Noah Misch <noah@leadboat.com>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
	Alexander Korotkov <aekorotkov@gmail.com>,
	Maxim Orlov <orlovmg@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
	Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>,
	Michael Paquier <michael@paquier.xyz>,
	Pavel Borisov <pashkin.elfe@gmail.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into
 PostgreSQL 15)
Message-ID: <20240626185844.00.nmisch@google.com>
References: 
 <CAJ7c6TPYPJ8YVD-GxjW-+Xdqodtoje+rVgQXUxdL2Kx+j5oG8w@mail.gmail.com>
 <b5f6c6ac-37da-b92d-a482-9171710d1a11@iki.fi>
 <CAJ7c6TPmzoPgj-4zdf+UqdV4GcoZag+=KTLpSJ3RHp5pYSxfZg@mail.gmail.com>
 <CAPpHfdtQhm1BXT9SL5jp1iOg=pN=A9pR98kwBCOQX4Pg=CY6mA@mail.gmail.com>
 <CAJ7c6TOUMe6izUX7r9t6zhK-X7La0fMgA4ru9BMniKAEv7pZKQ@mail.gmail.com>
 <CACG=ezbtS=nLBS6fedHxAjkBPRN-hyuHQ+su1VUtxWDsavDTYA@mail.gmail.com>
 <CACG=ezaOGAAmzqKjq=EDyqA6jNVtNFVvTc6-HstEy43swRqTog@mail.gmail.com>
 <CAPpHfduwDL29rGb_ONKwAsmq6bfMRgP+y+QkZJFUWuv2rDpb4g@mail.gmail.com>
 <20240626002747.dc.nmisch@google.com>
 <CAJ7c6TOqhfD04kEUjDgLGaCpq_JSv0F_S=sWWjHm+zNw4pqh2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAJ7c6TOqhfD04kEUjDgLGaCpq_JSv0F_S=sWWjHm+zNw4pqh2w@mail.gmail.com>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20240626185844.00.nmisch%40google.com>
Precedence: bulk

On Wed, Jun 26, 2024 at 02:09:58PM +0300, Aleksander Alekseev wrote:
> > This yielded commit 4ed8f09 "Index SLRUs by 64-bit integers rather than by
> > 32-bit integers" and left some expressions coercing SLRU page numbers to int.
> > Two sources:
> >
> >  grep -i 'int\b.*page' $(git grep -l SimpleLruInit)
> >  make && touch $(git grep -l SimpleLruInit) && make PROFILE=-Wconversion 2>&1 | less -p '.int. from .int64. may alter its value'
> >
> > (Not every match needs to change.)
> 
> I examined the new warnings introduced by 4ed8f09. Most of them seem
> to be harmless, for instance:
[...]
> I prepared the patch for clog.c. The rest of the warnings don't strike
> me as something we should immediately act on unless we have a bug
> report. Or perhaps there is a particular warning that worries you?

Is "int" acceptable or unacceptable in the following grep match?

src/backend/commands/async.c:1274:	int			headPage = QUEUE_POS_PAGE(QUEUE_HEAD);