alamb commented on issue #22723: URL: https://github.com/apache/datafusion/issues/22723#issuecomment-4622423197
> So to avoid getting too abstract, I'll raise a specific grounded question about not doing SLTs: To be clear I don't have anything for/against using SLT as a test harness, I am more concerned about the process and maintainability of the tests over the long term > [@alamb](https://github.com/alamb) and [@2010YOUY01](https://github.com/2010YOUY01) - what if I introduced a `SET runtime.enable_headroom = 5.0` that tests specifically opted into? Would that alleviate the concern? I think that would be better anyway as each test could 1. opt in 2. set it appropriately This sounds like a reasonable approach to me provided: 1. We clearly document what that setting does, when people should set it, and what they should do if their tests see an error related to it 2. We have some sort of longer term plan written down (like is the goal to remove all `enable_headroom` settings For example, Imagine a new contributor to DataFusion that writes a SLT test for some unrelated feature and it this error > 1. query failed: Other Error: allocator overdraft: account balance at panic = -1384887 bytes I think it would be very unclear what to do (maybe in the age of LLMs it is easier). Ideally we could make the error self explanatory and provide the answer of how to solve the issue > 1. query failed: Memory Accounting Mismatch: Plan used 1384887 bytes more actual memory than allowed. Please add a `SET runtime.enable_headroom = 5.0` and add this example to ticket https://... And then have the ticket explain the backstory and have a list of places where memory was over committed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
