https://s3.amazonaws.com/clickhouse-test-reports/34951/96390a9263cb5af3d6e42a84988239c9ae87ce32/stress_test__debug__actions_.html

By the way here I see only jemalloc exception, not uncaught exception.
Am I missing something?

@azat
Oops, I've attached wrong report

https://s3.amazonaws.com/clickhouse-test-reports/34951/96390a9263cb5af3d6e42a84988239c9ae87ce32/stress_test__undefined__actions_/clickhouse-server.err.log

Oops, I've attached wrong report

At least I've finally figured out why the assertion in jemalloc was hitting (hopefully).

https://s3.amazonaws.com/clickhouse-test-reports/34951/96390a9263cb5af3d6e42a84988239c9ae87ce32/stress_test__undefined__actions_/clickhouse-server.err.log

So maybe it worth to do proper destroy in StorageS3Sink, instead of adding try/catch in dtor.

@azat

Still not sure what's the proper way.

We can call cancel or finish for all processors for QueryPipeline::reset . Also maybe in ~QueryPipeline

But it would throw anyway. Also, should any retries be performed after errors from ~WriteBufferFromS3?

Let's merge current solution with try ... catch ... in ~WriteBufferFromS3, proper fix can be added later

But it would throw anyway. Also, should any retries be performed after errors from ~WriteBufferFromS3?

Yes, but it should call onFinish that calls WriteBufferFromS3::finalize and it will not throw from dtor since finalize will set to true, so finalize from dtor will be no-op.

what happened if finalize throw excaption? Looks like there is a possibility of data loss.

what happened if finalize throw excaption? Looks like there is a possibility of data loss.

Indeed, and to me it is better to abort over data loss.
That's why initially (#19451) there was no try/catch in dtors.