I don't think the failure is related - should we restart or, if def. not related, ignore (maybe restart since the change does touch an extension)?

Thanks for the PR!

Generally for TPC-H / TPC-DS we want to potentially generate higher scale factors, so having the scale factor to 777 could actually be limiting. The code is copied as-is, so it wouldn't surprise me if this overflow also exists in the original implementation.

I'm not sure how to best deal with this - we could fix the overflow by e.g. using unsigned integer arithmetic so that we wrap instead, but who knows in how many places these overflows exist. We also need to make sure we don't change the data that is generated which is time consuming to check at such high scale factors.

Hmmm - so currently we already cannot generate any scale factor beyond 777. With the changes here in place we at least make the problem apparent if we ever want to generate them by throwing an easy-to-understand exception... 🤔

we could fix the overflow by e.g. using unsigned integer arithmetic so that we wrap instead, but who knows in how many places these overflows exist

As for fixing this - I agree that I don't see a "good" solution that does not require fixing the copied-in code/changing the data generation...

I am also not sure if we actually want to go down the path of fixing this until we actually need to generate it?

Hmmm - so currently we already cannot generate any scale factor beyond 777. With the changes here in place we at least make the problem apparent if we ever want to generate them by throwing an easy-to-understand exception... 🤔

Is that due to a different reason than the signed integer overflow? Signed integer overflows, while technically undefined behavior, are in practice effectively always wrapping. In debug mode the sanitizers trigger, but in release mode they don't. If the original dsdgen contains the signed integer overflow then that means that is "expected" in a way, since all larger TPC-DS datasets including official ones would be generated with this overflow (likely triggering the wrapping behavior).

We could throw this exception in debug mode only using e.g. #ifdef DEBUG. Then we can still generate the large sets in release mode. Maybe we want to eventually fix this but agreed this is low priority.

In debug mode the sanitizers trigger, but in release mode they don't. If the original dsdgen contains the signed integer overflow then that means that is "expected" in a way, [...] We could throw this exception in debug mode only using e.g. #ifdef DEBUG.

Okay - I've removed the test now since I don't think we can tag it as "only run in debug mode" (AFAIK). I've also wrapped the exception in #ifdef DEBUG. Then, we can close the fuzzer issue so the fuzzer no longer triggers on this, I'd say?

Thanks!