On Fri, Feb 13, 2026 at 1:08 AM Álvaro Herrera <[email protected]> wrote:
> On 2026-Feb-13, Yasir wrote: > > > can we add alternative test output files for the changes caused by > > different block sizes? E.g: the attached poc patch. Whether such an > > approach would be acceptable? > > Absolutely not. For starters, how did you verify that these new files > are correct? I'm not sure whether this POC file (or other files) is accurate. Clearly, if we proceed with this approach to address the regression issues, it will need to be verified by expert reviewers. > Second, I imagine this patch is just for this one file, > but that there numerous other files that would have to be patched, > right? If so, how many, and how extensive are the changes? > Correct. I have reviewed the entire set, approximately 30 files, and all of them require adjustments to their outputs. The necessary changes are largely similar to the modifications shown in the alternative output file referenced above. > If you wanted to propose some surgical interventions to the affected > files that made the tests pass for other page sizes, then perhaps that > could be entertained. Looking at the files you sent, I see that from > the original to _2.out there are two plan changes (hash aggregates > become group aggregates); then from _2.out to _1.out a single query > changes from indexscan to bitmap scan; and lastly, from the original to > _3.out there are some seqscans that become index scans. So if you were > to propose a patch that adds a SET call to disable some plan type just > before one query, and RESET it immediately after that query; and with > such a change the test runs unchanged across all block sizes, then maybe > that would be something we could consider. (However, getting a > committer to review such changes might be a hard sell also -- no > promises!) > Thank you, you've hit the nail on the head. By comparing the alternative outputs to the original, you've clearly understood what I was aiming for. As for the SET/RESET solution, I hadn't considered that approach myself; it's an interesting angle. As long as it doesn't compromise the purpose of the regression, it looks like a solid approach. > > Also, if you find that you need too many changes of this kind in order > to make this work, then that's probably not going to fly either. > There are around 30 files in total that will need alternative outputs. > > > Which other compile time options are expected to cause test failures? > > You're welcome to experiment and let us know what you find. > I'll experiment, assuming I get a chance in this lifetime! :) > -- > Álvaro Herrera Breisgau, Deutschland — > https://www.EnterpriseDB.com/ >
