Describe the bug or unexpected behaviour
The DROP PARTITION command seem to work well and return appropriate result when we just execute it. But if we restart ClickHouse, a simple query return more column than it should be.

How to reproduce
ClickHouse server version 19.17.6 revision 54428

CREATE TABLE IF NOT EXISTS drop_part (
    pk UInt8,
    val UInt32
) Engine = MergeTree()
  PARTITION BY pk
  ORDER BY (pk, val);

INSERT INTO drop_part SELECT number % 2, number FROM system.numbers LIMIT 10000000;

SELECT COUNT() FROM drop_part; -- Show 10000000

ALTER TABLE drop_part DROP PARTITION 1;

SELECT COUNT() FROM drop_part; -- Show 5000000

Then we should stop ClickHouse, and restart it.

Then, when CH has been restarted, if we do again a SELECT COUNT() FROM drop_part, CH return 8145728, with 3145728 when we do the command SELECT COUNT() FROM drop_part WHERE pk = 1

Expected behavior
The command, after the restart, should return 5000000 rows, with 0 rows if we try to filter with a pk equal to one.

Additional context
It also seem on the table system.parts, we don't fully drop the partition even before the restart.

For example on the example I given, before the restart, the command select * from system.parts WHERE table = 'drop_part' AND partition = '1' return 11 rows, while after the drop, the same command return 6 rows, while it should return 0.

edit: slight note on the additional context, it seem the partitions are removed after a certain time. Otherwise if we shutdown CH after the drop, the partition is not remove