**Describe what's wrong**

Wrong table name in logs after table `RENAME`


**Does it reproduce on recent release?**

Yes.
**How to reproduce**
22.6

```
CREATE TABLE table_test_a
(
    `key` UInt32
)
ENGINE = MergeTree
ORDER BY key;

INSERT INTO table_test_a SELECT *
FROM numbers(1000);

RENAME TABLE table_test_a TO table_test_b;

SELECT *
FROM table_test_b
FORMAT `Null`;


[LAPTOP-] 2022.06.13 10:58:18.370192 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> executeQuery: (from 127.0.0.1:58484) SELECT * FROM table_test_b FORMAT Null; (stage: Complete)
[LAPTOP-] 2022.06.13 10:58:18.370599 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> ContextAccess (default): Access granted: SELECT(key) ON test.table_test_b
[LAPTOP-] 2022.06.13 10:58:18.370665 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> ContextAccess (default): Access granted: SELECT(key) ON test.table_test_b
[LAPTOP-] 2022.06.13 10:58:18.370714 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> InterpreterSelectQuery: FetchColumns -> Complete
[LAPTOP-] 2022.06.13 10:58:18.370783 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> test.table_test_a (SelectExecutor): Key condition: unknown
[LAPTOP-] 2022.06.13 10:58:18.370817 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> test.table_test_a (SelectExecutor): Selected 1/1 parts by partition key, 1 parts by primary key, 1/1 marks by primary key, 1 marks to read from 1 ranges
[LAPTOP-] 2022.06.13 10:58:18.370847 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> MergeTreeInOrderSelectProcessor: Reading 1 ranges in order from part all_1_1_0, approx. 1000 rows starting from 0
[LAPTOP-] 2022.06.13 10:58:18.371812 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Information> executeQuery: Read 1000 rows, 3.91 KiB in 0.0015354 sec., 651296 rows/sec., 2.48 MiB/sec.
[LAPTOP-] 2022.06.13 10:58:18.371956 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> MemoryTracker: Peak memory usage (for query): 45.10 KiB.
```
**Expected behavior**

Correct table name in logs


**Additional context**

Interesting, does it affect grants and etc (looks like no, in ContextAccess log it's using correct table name )

size_t suspicious_broken_parts = 0;
    size_t suspicious_broken_parts_bytes = 0;
    std::atomic<bool> has_adaptive_parts = false;
    std::atomic<bool> has_non_adaptive_parts = false;
    std::mutex mutex;
    auto load_part = [&](const String & part_name, const DiskPtr & part_disk_ptr)
    {
        auto part_opt = MergeTreePartInfo::tryParsePartName(part_name, format_version);
        if (!part_opt)
            return;
        const auto & part_info = *part_opt;
        auto single_disk_volume = std::make_shared<SingleDiskVolume>("volume_" + part_name, part_disk_ptr, 0);
        auto data_part_storage = std::make_shared<DataPartStorageOnDisk>(single_disk_volume, relative_data_path, part_name);
        auto part = createPart(part_name, part_info, data_part_storage);
        bool broken = false;
        String part_path = fs::path(relative_data_path) / part_name;
        String marker_path = fs::path(part_path) / IMergeTreeDataPart::DELETE_ON_DESTROY_MARKER_FILE_NAME;
        if (part_disk_ptr->exists(marker_path))
        {
            
            size_t size_of_part = data_part_storage->calculateTotalSizeOnDisk();
            LOG_WARNING(log,
                "Detaching stale part {}{} (size: {}), which should have been deleted after a move. "
                "That can only happen after unclean restart of ClickHouse after move of a part having an operation blocking that stale copy of part.",
                getFullPathOnDisk(part_disk_ptr), part_name, formatReadableSizeWithBinarySuffix(size_of_part));
            std::lock_guard loading_lock(mutex);
            broken_parts_to_detach.push_back(part);
            ++suspicious_broken_parts;
            suspicious_broken_parts_bytes += size_of_part;
            return;