Fix std::out_of_range when reading from Buffer table with sample

[kssenii]

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fix crash on usage of Buffer table with SAMPLE when destination does not support it.

Documentation entry for user-facing changes

Closes #99134

• Documentation is written (mandatory for new features)

---

Note

Low Risk
Low risk bug fix that adds a guard and a regression test; behavior changes only when SAMPLE is used on tables without a sampling key, now returning a clear SAMPLING_NOT_SUPPORTED error instead of potentially crashing.

Overview
Prevents a crash when executing SAMPLE against a MergeTree-backed Buffer table whose destination MergeTree has no SAMPLE BY key.

MergeTreeDataSelectExecutor::getSampling() now explicitly checks metadata_snapshot->hasSamplingKey() before accessing the sampling key and throws ErrorCodes::SAMPLING_NOT_SUPPORTED with a clear message when absent.

Adds a stateless regression test covering the failing Buffer+MergeTree case (expects SAMPLING_NOT_SUPPORTED) and confirms SAMPLE still works for Buffer tables without a destination table (in-memory only).

^{Written by Cursor Bugbot for commit f5aec3e. This will update automatically on new commits. Configure here.}

[clickhouse-gh]

Workflow [PR], commit [f5aec3e]

Summary: ✅

[azat]

Hm, is the following possible?

SELECT * FROM buffer:

• getSampling() == return true -- because underlying table supports sampling
• then another thread re-create table w/o sampling, in the middle of that SELECT
• then StorageBuffer::read calls getDestinationTable again and got table that does not support it

I think so. Then we need a check in MergeTreeDataSelectExecutor::getSampling

[clickhouse-gh]

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	83.80%	83.80%	+0.00%
Functions	23.90%	23.90%	+0.00%
Branches	76.30%	76.30%	+0.00%

PR changed lines: PR changed-lines coverage: 100.00% (7/7)
Diff coverage report
Uncovered code

[azat]

BTW do we have the same problem for i.e. views?

[azat]

I think it also make sense to test Buffer over MergeTree table with sampling, just in case

[kssenii]

I see there is such test already

ClickHouse/tests/queries/0_stateless/00061_storage_buffer.sql

Lines 5 to 12 in f8a8eb2

	CREATE TABLE hits_dst AS test.hits
	ENGINE = MergeTree
	PARTITION BY toYYYYMM(EventDate)
	ORDER BY (CounterID, EventDate, intHash32(UserID))
	SAMPLE BY intHash32(UserID)
	SETTINGS storage_policy = 'default';
	CREATE TABLE hits_buffer AS hits_dst ENGINE = Buffer(current_database(), hits_dst, 8, 600, 600, 1000000, 1000000, 100000000, 1000000000);

[kssenii]

BTW do we have the same problem for i.e. views?

I'll check, but I'd merge this PR for now.