Feedback-ID: ia2694551:Fastmail
Date: Fri, 24 Feb 2023 09:39:16 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
	Justin Pryzby <pryzby@telsasoft.com>,
	Andres Freund <andres@anarazel.de>, Greg Stark <stark@mit.edu>,
	Zhihong Yu <zyu@yugabyte.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PATCH: Using BRIN indexes for sorted output
Message-ID: <20230224083916.tn4ikos65f4ep2od@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAEze2Whd=MCQ61EEUUWJgohHN5cm3bv027N+vS4o6zOuBTY3tw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230224083916.tn4ikos65f4ep2od%40alvherre.pgsql>
Precedence: bulk

On 2023-Feb-23, Matthias van de Meent wrote:

> > + for (heapBlk = 0; heapBlk < nblocks; heapBlk += pagesPerRange)
> 
> I am not familiar with the frequency of max-sized relations, but this
> would go into an infinite loop for pagesPerRange values >1 for
> max-sized relations due to BlockNumber wraparound. I think there
> should be some additional overflow checks here.

They are definitely not very common -- BlockNumber wraps around at 32 TB
IIUC.  But yeah, I guess it is a possibility, and perhaps we should find
a way to write these loops in a more robust manner.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"World domination is proceeding according to plan"        (Andrew Morton)