Re: Confine vacuum skip logic to lazy_scan_skip
| От | John Naylor | 
|---|---|
| Тема | Re: Confine vacuum skip logic to lazy_scan_skip | 
| Дата | |
| Msg-id | CANWCAZbNQMrN0YRW4Lj3h9ACSDnL84+hNN1JTfAisgYVftX4Gg@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Confine vacuum skip logic to lazy_scan_skip (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: Confine vacuum skip logic to lazy_scan_skip
            		
            		 | 
		
| Список | pgsql-hackers | 
On Wed, Oct 22, 2025 at 11:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > The reason it thinks that num_offsets could be as much as 2048 is > presumably the code a little bit above this: > > OffsetNumber offsets[MaxOffsetNumber]; > ... > num_offsets = TidStoreGetBlockOffsets(iter_result, offsets, lengthof(offsets)); > Assert(num_offsets <= lengthof(offsets)); > > However, lazy_vacuum_heap_page blindly assumes that the passed value > will be no more than MaxHeapTuplesPerPage. It seems like we ought > to get these two functions in sync, either both using MaxOffsetNumber > or both using MaxHeapTuplesPerPage for their array sizes. > > It looks to me like MaxHeapTuplesPerPage should be sufficient. Seems right. > Also, after reading TidStoreGetBlockOffsets I wonder if we > should replace that Assert with > > num_offsets = Min(num_offsets, lengthof(offsets)); > > Thoughts? Not sure. That changes the posture from "can't happen" to "shouldn't happen, but if it does, don't cause a disaster". Even with the latter, the assert still seems appropriate for catching developer mistakes. -- John Naylor Amazon Web Services
В списке pgsql-hackers по дате отправления: