On Sat, May 10, 2025 at 10:59 AM Tomas Vondra <to...@vondra.me> wrote: > But doesn't it also highlight how fragile this memory allocation is? The > skip scan patch didn't do anything wrong - it just added a couple > fields, using a little bit more memory. I think we understand allocating > more memory may need more time, but we expect the effect to be somewhat > proportional. Which doesn't seem to be the case here. > > Many other patches add fields somewhere, it seems like bad luck the skip > scan happened to trigger this behavior. It's quite likely other patches > ran into the same issue, except that no one noticed. Maybe the skip scan > did that in much hotter code, not sure.
But what did the skip scan commit (specifically commit 92fe23d9, without any of the follow-up commits) change about memory allocation, that might be at issue with your test case? You said that that commit "just added a couple fields". What specific fields are you talking about, that were added by commit 92fe23d9? I already speculated that the issue might be tied to the addition of a new support routine (skip support), but the experiment we ran to try to validate that theory disproved it. What else is there? Again, commit 92fe23d9 didn't make BTScanOpaqueData any larger (follow-up commit 8a510275 added a new BTScanOpaqueData.skipScan bool field, but that didn't even affect sizeof BTScanOpaqueData, since the field fit into what was previously just alignment padding space). AFAICT nothing that seems like it might be relevant changed, apart from the addition of the new support routine, which was ruled out already. -- Peter Geoghegan
