Кто-нибудь сталкивался на 18.14.9( "самосборка" ) CentOS с : <Error> ExternalDictionaries: Cannot create external dictionary 'PG_DICT_ADDRESSES' from config path /etc/clickhouse-server/postgre_dict_addresses_dictionary.xml: Code: 86, e.displayText() = DB::Exception: Received error from remote server /identifier_quote?connection_string=DSN%3Dpostgres. HTTP status code: 500 Internal Server Error, body: No 'query' in request body ? При этом, на Debian та же версия работает без проблем. Может не так собираю?

столкнулся с тем же самым. 18.14.10 на центосе, решается "убиванием" процесса odbc-bridge и запуском сервера заново. Все поднимается нормально тогда.

Проблема, похоже, не в драйвере, а в том, что датафрейм конвертирует не в то, что надо. Тогда другой вопрос - какого хрена? И что с этим можно сделать?

привет, а как репликейтед таблицы создаются новым синтаксисом?

Пока никто не репортил. Интересно, можно ли как-нибудь изолировать причину?

это у вас проблемы с зк , обычно бывает когда перевыбор лидера происходит

а где у вас зк стоит ?

Три отдельный сервачка

к вопросу про ЗК, 3.4.5 есть смысл на что-то более свежее обновить? претензий к его работе нет, но всеже

Нет проблем нет смысла

Посмотрите системные логи и логи зк , думаю как то связано все таки что они теряют сеть или лидера

Ну смотрите системные логи

А зачем xfs когда все очень хорошо работает на ext4?

А сервер у вас так и должен быть загружен чтением ?

А сервер у вас так и должен быть загружен чтением ?

это большие мержи

Работает ли ALTER TABLE DELETE с подзапросом? ALTER TABLE table_1 DELETE WHERE col_1 in (SELECT col_1 FROM table_1 WHERE col_2 = x AND col_3 = y )

Мне кажется у вас там получится ересь , почитайте как работает делете он же не атомарно идёт

Я так понимаю причина в том что он не кеширует подзапрос? И не понимает что именно удалять? Он принял мутацию command DELETE WHERE col_1 IN ((SELECT history_id FROM table_1 WHERE col_2 = 100) AS _subquery1)

Ну если синтаксис правильный то конечно принял, это же не значит что будет делать

Ну если синтаксис правильный то конечно принял, это же не значит что будет делать

Ясно. Но это похоже на баг.

Вы вообще не читали как оно работает видимо

Я понимаю, что применяется к каждой партиции, по очереди. Но вопрос в том что он принял запрос и не выполнил его. У меня к этому вопросы. Ведь можно добавить признак состояния fail, кроме is_done, Тк не ясно - возможно она принята и выполняется, потребляет ресурс, но не заканчивается. А правильность синтаксиса - это вообще не аргумент.

Не слушайте этого молодого человека :). Все знают, как это работает, вопрос лишь в том, почему ошибки не выдаются или почему они не ясны. Если запрос ошибочный и точно не может быть выполнен, должна выдаваться ошибка сразу, а не потом.

Работает ли ALTER TABLE DELETE с подзапросом? ALTER TABLE table_1 DELETE WHERE col_1 in (SELECT col_1 FROM table_1 WHERE col_2 = x AND col_3 = y )

Не слушайте этого молодого человека :). Все знают, как это работает, вопрос лишь в том, почему ошибки не выдаются или почему они не ясны. Если запрос ошибочный и точно не может быть выполнен, должна выдаваться ошибка сразу, а не потом.

Ну реально нельзя выдавать желаемое за действительное.

А какая версия у вас?

Ну может и нельзя, однако всё же стоит стремиться к тому, чтобы те вещи, которые можно проверить перед выполнением альтера, собственно проверить. И если известно, что нельзя сделать DELETE с SELECT на ту же таблицу, это должно анализироваться перед выполнением операции и выдаваться ошибка. Это очень сильно экономит время при отладке проблем.

SELECT version()

Ну а как проверить то? Вот ты туда засунули в селект вечный запрос, как узнать что он вечный не исполнив его?

Сейчас работает, правда неэффективно - подзапрос выполняется на каждый изменяемый кусок.

Я могу без подзапроса перечислить записи какие необходимо удалить, но мне удобнее было использовать подзапрос. Я локально не имею 1000М записей, у меня 2М - тут нет вечного запроса.

Ну написать какой нибудь вечный же запрос не проблема как кх может узнать вечный он или нет, синтаксис будет ок, поэтому кх может проверить только синтаксис, ну в лучшем случае таймаут

Ну написать какой нибудь вечный же запрос не проблема как кх может узнать вечный он или нет, синтаксис будет ок, поэтому кх может проверить только синтаксис, ну в лучшем случае таймаут

Каждый раз ровно при исчерпании cached?

Пока что не пробовали изолировать, но более-менее уверены в том, что именно в посылке некорректных запросов (с несуществующей фунцией) заключается проблема, потому что на других хостах с той же версией таких проблем мы не наблюдали :).

Да, при работе с подзапросами в мутациях был баг - попробуйте как минимум 18.12.17

Перешел на 18.12.17. Но очередь мутаций на таблице зависла. Если создать новую то она становиться следующей и ждет другие. Можно ли как-то сбросить зависшие мутации?

Придётся вручную удалить. У вас обычные MergeTree или реплицированные?

MergeTree

Всем привет! Я тут тулу для бэкапа кликхауса написал. Буду раз если найдутся желающие потестить и issue завести https://github.com/AlexAkulov/clickhouse-backup