Experimental MaterializedPostgreSQL crash

[nikandfor]

Describe what's wrong

Experimental MaterializedPostgreSQL db engine crashes. As I understood, it started happening when UPDATE was made on a source database. Then it started to crash database after a minute when restarted. I can't even drop the database.

As I understand UPDATE should be supported and handled by ReplacingMergeTree, am I right?

Does it reproduce on recent release?

I used the latest tag of docker image "yandex/clickhouse-server:latest" which was "sha256:c739327b5607ac47030e5de03542072f21912a4226f18de912a6e6126af28014"

The list of releases

Enable crash reporting

This is against company's security policy.

How to reproduce

• Which ClickHouse server version to use

Starting ClickHouse 22.1.3.7 with revision 54458, build id: D11BC54A7FE20E44, PID 1

• Which interface to use, if matters

none

• Non-default settings, if any

<allow_experimental_database_materialized_postgresql>1</allow_experimental_database_materialized_postgresql>

• CREATE TABLE statements for all tables involved

CREATE DATABASE IF NOT EXISTS db_name
ENGINE = MaterializedPostgreSQL('host', 'remote_database', 'user', 'password')
SETTINGS materialized_postgresql_tables_list = `13_tables_here`

One of postgres tables schema

• Sample data for all these tables, use clickhouse-obfuscator if necessary
• Queries to run that lead to unexpected result

 UPDATE table SET col = 100000005 WHERE id = 1;

Expected behavior

Sync well, print error, stop syncing, but not crash.

Error message and/or stacktrace

void DB::MaterializedPostgreSQLConsumer::syncTables(): Code: 393. DB::Exception: There is no query or query context has expired. (TH

0. DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int, bool) @ 0xa82d07a in /usr/bin/clickhouse
1. DB::Context::getQueryContext() const @ 0x1349d34a in /usr/bin/clickhouse
2. DB::buildPushingToViewsChain(std::__1::shared_ptr<DB::IStorage> const&, std::__1::shared_ptr<DB::StorageInMemoryMetadata const> const&, std::__1::shared_ptr<DB::Context const>
3. DB::InterpreterInsertQuery::buildChainImpl(std::__1::shared_ptr<DB::IStorage> const&, std::__1::shared_ptr<DB::StorageInMemoryMetadata const> const&, DB::Block const&, DB::Thr
4. DB::InterpreterInsertQuery::execute() @ 0x13a4ceb4 in /usr/bin/clickhouse
5. DB::MaterializedPostgreSQLConsumer::syncTables() @ 0x13310cd1 in /usr/bin/clickhouse
6. DB::MaterializedPostgreSQLConsumer::readFromReplicationSlot() @ 0x1331262c in /usr/bin/clickhouse
7. DB::MaterializedPostgreSQLConsumer::consume(std::__1::vector<std::__1::pair<int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::
8. DB::PostgreSQLReplicationHandler::consumerFunc() @ 0x132ddf20 in /usr/bin/clickhouse
9. DB::BackgroundSchedulePoolTaskInfo::execute() @ 0x12f8470e in /usr/bin/clickhouse
10. DB::BackgroundSchedulePool::threadFunction() @ 0x12f870a7 in /usr/bin/clickhouse
11. ? @ 0x12f88170 in /usr/bin/clickhouse
12. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0xa86f4b7 in /usr/bin/clickhouse
13. ? @ 0xa872ebd in /usr/bin/clickhouse
14. ? @ 0x7f849be4d609 in ?
15. __clone @ 0x7f849bd74293 in ?
 (version 22.1.3.7 (official build))

Additional context

Log file from restart until crash. With table schemas removed.
click.log

[nikandfor]

I mislead you, it actually catches the exception and shuts down. But anyway I couldn't make it working back.

[kssenii]

Ok, so there is no crash and it just does not let the server start because there is an exception on startup?

[nikandfor]

Yes, it shut down when I made an UPDATE request and do it when starting again.

[kssenii]

This should be not as simple as just making update, as different update versions are tested in CI: https://github.com/ClickHouse/ClickHouse/blob/master/tests/integration/test_postgresql_replica_database_engine_1/test.py#L451

[nikandfor]

How can I get more details about error?

[kssenii]

I found the reason by rereading the code and the stacktraces from the click.log file you attached. Here is the fix #35614.

[nikandfor]

Superfast! Thanks, I'll check it soon.