Workflow [PR], commit [10ab690]

Summary: ❌

Fast tests are failing in interesting ways; I’ll look into it.

enable_shared_storage_snapshot_in_query by default for better consistency guarantees. There should be no downsides.

There is one problem for long running queries

If you have a query that removes almost all parts during pruning, then all parts that are not used for SELECT can be removed at any time (even if query takes hours), but with this setting enabled this will not be possible, and I've already experienced issues with this here - #37913

Dear @azat, this PR hasn't been updated for a while. You will be unassigned. Will you continue working on it? If so, please feel free to reassign yourself.

@azat, how big is the problem in practice, I mean, does it justify not having this by default?

@amosbird, something is related to the mergeTreeProjection table function.

@azat, how big is the problem in practice, I mean, does it justify not having this by default?

It is big if you have

• long running queries (that blocks parts from removing)
• real-time ingestion
• parts located on HDD

This may lead to a situation when HDDs will not be able to remove parts fast enough

But, maybe it is a sensible default...

@amosbird, something is related to the mergeTreeProjection table function.

It's already resolved.

@amosbird, it's unclear to me why tests for FileLog have failed, maybe you will have a chance to find the reason quicker?

Sure. I’ll investigate it later this week.

@alexey-milovidov The issue happens because FileLog doesn’t properly clean up the context between view invocations, unlike StorageKafka and StorageObjectQueue, where this is already handled correctly. I’ve fixed it in #88810 together with similar adjustments for other storage types. Also randomized this setting in tests to potentially catch more related issues.

@amosbird, we have a similar problem with MaterializedPostgreSQL.

@amosbird, for some reason, tests for MaterializedPostgreSQL are still failing.

There is also one more issue, that will be addressed here - #89283

for some reason, tests for MaterializedPostgreSQL are still failing.

Lemme check...

It should be fixed by #89795