Dennis Felsing

In 2.17.2.0-b39 this also occurred in org.yb.pgsql.TestPgRegressIndex.testPgRegressIndex: > pg_regress exited with error code: 1, failed tests: [yb_create_index] ``` F20230120 02:27:35 ../../src/yb/util/rwc_lock.cc:150] Too long write lock wait, last writer TID: 409433,...

Let's get this in for next release: > So you think it makes sense to default to Vulkan for next release? Would probably also be a good time to add...

bors r+ Thanks, another big improvement.

Indeed, strange. This sounds like it should fail: > Testing upgrade from Materialize v0.86.1 to current_source.

This is kind of awkward for the legacy upgrade tests. They are supposed to start on a specific version and check that the migrations inbetween work to the current version....

Let me try to implement this and push it into this PR when I'm done. Edit: Seems to work: https://buildkite.com/materialize/tests/builds/77841#018e18e3-0b87-4911-a49c-1860815e14d8

Yes, good to go imo.

`forced optimizer panic` is something that should just be ignored, and is already. The inconsistent-view-outcome is the interesting part.

Got the OoM reproduced with heap profile, the last profile still looked similar but had grown to 1800 MB: [mz_2-2024-02-16_14 16 23.pb.gz](https://github.com/MaterializeInc/materialize/files/14313173/mz_2-2024-02-16_14.16.23.pb.gz) 

Yes, sqlsmith runs a bunch of explain plans continuously for 6000 s, nothing else.. Let me try if `bin/mzcompose --find sqlsmith run default --explain-only --runtime 6000` reproduces it and whether...