Dennis Felsing

@danhhz This was last touched in https://github.com/MaterializeInc/materialize/pull/19646 This panic happened in Mz Staging env.

I think this is not a regression, but a flake that got exposed by having faster testdrive via https://github.com/MaterializeInc/materialize/pull/25731

I'm a bit confused because I thought the testdrive would already wait here for a bit until the result becomes correct.

storage-usage could probably be adapted for this, it has a PG_CDC setup already, so there could be a test with a larger amount of data in PG. Alternatively but a...

Can you easily run the client with asan? That will probably tell you a bit more, without us having to look into how you switched designs

I think I added that since I found some bugs when running it on 32bit, I assume wrong results. But haven't tried in a while obviously, so not sure what...

Just the internal tests I guess

I was in a hurry and totally forgot: `niminst csources foo.ini` You have to manuall add a `lib` directory and put the `nimbase.h` in there. In other directories it doesn't...

Also seen in parallel-workload today locally while trying to repro https://github.com/MaterializeInc/materialize/issues/22717: ``` git checkout cdbb5b6756a82498f28aa68350bb448cf2c84dd7 bin/mzcompose --find parallel-workload run default --seed=1700062842 --threads=32 --runtime=3000 --complexity=ddl --scenario=regression ``` ``` thread 'timely:work-2' panicked...

This is still happening commonly in CI, see for example https://buildkite.com/materialize/tests/builds/77445#018e0a6e-3213-41df-966f-8387b87cc0eb