Лично для меня куда интересней был бы поиск наличия пересечений одного диапазона с одним из множества других. Скорее всего, оптимально это можно сделать с использованием R-Tree, но не исключаю и иные вариант.
Просто не возвращайте соединение в пул, продолжая его использовать. Излишние DISCARD ALL (по сути, последовательность из девяти команд) в данном случае только вредят.
“процесс/соединение живо” ≠ “воркер делает progress”
Зависит от настроек соединения. При правильных настройках для конкретного сценария использования соединение не долго будет висеть открытым.
Heartbeat решает именно это: “если давно не пинговал — считаем мёртвым”, даже если TCP/процесс жив.
Но создает транзакции, модифицирует БД и пишет в WAL, загружая не только сервер, но ещё и его реплики в кластере. Тогда как установив необходимый idle_session_timeout для своей сессии можно добиться того же самого, посылая команды не порождающие транзакции и модификации БД. Например, SHOW.
Есть даже институты переподготовки и повышения квалификации, куда принимают только с дипломом о высшем образовании. В качестве исключения - по академической справке о неоконченном высшем образовании.
есть только последнее
Каким образом диплом экономиста может отменить диплом инженера-схемотехника?
Если вместо (или кроме) абстрактного worker_id фиксировать в таблице pg_backend_pid(), то никакого heartbeat не требуется. Достаточно по pg_stat_activity проверять наличие pid и сравнивать backend_start с временем последней модификации задачи. Если backend_start больше времени модификации задачи или такого pid нет в pg_stat_activity, то процесс умер и блокировки нет.
В моей жизни был так же период работы аналитиком. Для этого мне пришлось получать второе высшее образование - экономическое. На множестве других проектов мне порой самому приходилось искать в команду аналитиков. И опять главным требованием было глубокое понимание проблемной части: экономики, энергетики, логистики, производства и т.п. А уж обучить до необходимого аналитику уровня SQL и Python куда проще, чем, для примера, технологии производства минеральных удобрений или экономической основы формирования цен для ПСДЦ.
Это субъективно и зависит от контекста. При этом я специально указал, как при помощи того же самого udev делать идентификацию не только по serial, но и по devpath. Вы возражаете против свободы выбора?
Тут первая строка - для встроенного в мой ноут второго порта USB3.0. Вторая - для шестого порта внешнего семипортового USB3.0 хаба. Третья - для седьмого порта того же хаба.
Лично для меня идентификация только по by-path не кажется удобной, так как при наличии большого количество устройств не очень-то поймёшь, куда какой воткнул.
Зато, для примера, ESP32-С3 замечательно идентифицируются по серийному номеру, что позволяет давать произвольные имена устройствам.
Bus 001 Device 015: ID 303a:1001 Espressif USB JTAG/serial debug unit
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 [unknown]
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x303a Espressif
idProduct 0x1001 USB JTAG/serial debug unit
bcdDevice 1.01
iManufacturer 1 Espressif
iProduct 2 USB JTAG/serial debug unit
iSerial 3 80:65:99:2D:19:64
На всякий случай, приведу пример использования. Создаем файл /etc/udev/rules.d/91-esp32.rules с содержимым:
Вы заблуждаетесь. В случае императивного языка, результирующий код однозначно определяется исходным кодом и используемым компилятором, включая его опции компиляции. В случае же декларативного языка, результирующий код очень сильно зависит от окружения перед его выполнением.
В случае SQL, план запроса определяется, как минимум, значениями статистик в БД на момент начала выполнения запроса. То есть, планы двух одинаковых SQL запросов, даже на одной и той же БД, могут сильно отличаться друг от друга. И это нормально.
Насколько я понял, описываемое решение применяется в случаях, когда 16 или более прерываний в секунду (раз в 64 мс) - это слишком часто. Я с такими случаями не сталкивался, но исключить их возможность не могу.
Прерывания раз в час (или раз в 71 минуту) уж точно навредить не могут, поэтому просто старшие 32 бита счетчика храним в памяти и оперируем 64-битным значением, которое за время существования нашего МК точно не переполнится.
Если же прерывания по переполнению таймера раз в 64 мс допустимы, то можно использовать 16-битный таймер и тоже 32 бита счетчика в памяти. 48 бит хватит лет на шесть, так что раз в 5-6 лет надо будет перезагружаться, что выглядит некритичным ограничением.
Идея здравая, плюсую. Но хотелось бы узнать, в каких случаях 20 прерываний в секунду (каждые 50 мс), могут оказать критическое влияние на работу устройства?
Универсальность - это хорошо и востребовано. Но любая универсальность - это поиск компромиссов. Поэтому, например, колоночное хранение в PostgreSQL и в ClickHouse - это две разные вещи, имеющие критически важные отличия.
Если упрощённо, то трактором можно копать, но он не конкурент карьерному экскаватору. Трактором можно убирать зерно, но он не конкурент зерноуборочному комбайну.
Поэтому я не против новых возможностей у PostgreSQL, но только до тех пор, пока они являются не основными и их внедрение не влияет отрицательно на основные функции РСУБД.
Лично для меня куда интересней был бы поиск наличия пересечений одного диапазона с одним из множества других. Скорее всего, оптимально это можно сделать с использованием R-Tree, но не исключаю и иные вариант.
По сравнению, для примера, с утерей накоплений в ценных бумагах или (крипто)валюте - это меньшая из бед.
Доступ к содержимому может и получат, но расшифруют ли его не зная паролей к ключам, использованным для шифрования?
Спасибо, не надо, так как стоимость поддержки такого решения будет астрономической.
Про то и речь, что конкретные задачи возникают чуть ли не каждую неделю
Просто не возвращайте соединение в пул, продолжая его использовать. Излишние DISCARD ALL (по сути, последовательность из девяти команд) в данном случае только вредят.
Зависит от настроек соединения. При правильных настройках для конкретного сценария использования соединение не долго будет висеть открытым.
Но создает транзакции, модифицирует БД и пишет в WAL, загружая не только сервер, но ещё и его реплики в кластере. Тогда как установив необходимый idle_session_timeout для своей сессии можно добиться того же самого, посылая команды не порождающие транзакции и модификации БД. Например, SHOW.
Не складыватся
Есть даже институты переподготовки и повышения квалификации, куда принимают только с дипломом о высшем образовании. В качестве исключения - по академической справке о неоконченном высшем образовании.
Каким образом диплом экономиста может отменить диплом инженера-схемотехника?
Если вместо (или кроме) абстрактного worker_id фиксировать в таблице pg_backend_pid(), то никакого heartbeat не требуется. Достаточно по pg_stat_activity проверять наличие pid и сравнивать backend_start с временем последней модификации задачи. Если backend_start больше времени модификации задачи или такого pid нет в pg_stat_activity, то процесс умер и блокировки нет.
В моей жизни был так же период работы аналитиком. Для этого мне пришлось получать второе высшее образование - экономическое. На множестве других проектов мне порой самому приходилось искать в команду аналитиков. И опять главным требованием было глубокое понимание проблемной части: экономики, энергетики, логистики, производства и т.п. А уж обучить до необходимого аналитику уровня SQL и Python куда проще, чем, для примера, технологии производства минеральных удобрений или экономической основы формирования цен для ПСДЦ.
Это субъективно и зависит от контекста. При этом я специально указал, как при помощи того же самого udev делать идентификацию не только по serial, но и по devpath. Вы возражаете против свободы выбора?
В случае отсутствия серийного номера, как для CH340, действительно приходится ориентироваться на by-path. Но для этого тоже достаточно udev. Например:
Тут первая строка - для встроенного в мой ноут второго порта USB3.0. Вторая - для шестого порта внешнего семипортового USB3.0 хаба. Третья - для седьмого порта того же хаба.
Лично для меня идентификация только по by-path не кажется удобной, так как при наличии большого количество устройств не очень-то поймёшь, куда какой воткнул.
Зато, для примера, ESP32-С3 замечательно идентифицируются по серийному номеру, что позволяет давать произвольные имена устройствам.
На всякий случай, приведу пример использования. Создаем файл /etc/udev/rules.d/91-esp32.rules с содержимым:
Перезагружаем правила udev
Подключаем ESP32-C3 с серийным номером, указанным выше и видим симлинк /dev/gate_control_dev_1
Это решение не применимо, когда пароли для различных сервисов приходится вводить на самых различных серверах, на которые зашел по ssh, vnc или rdp.
Хорошо, если есть возможность аутентификации по ключу или через локальный keytab. А если нет?
Вы заблуждаетесь. В случае императивного языка, результирующий код однозначно определяется исходным кодом и используемым компилятором, включая его опции компиляции. В случае же декларативного языка, результирующий код очень сильно зависит от окружения перед его выполнением.
В случае SQL, план запроса определяется, как минимум, значениями статистик в БД на момент начала выполнения запроса. То есть, планы двух одинаковых SQL запросов, даже на одной и той же БД, могут сильно отличаться друг от друга. И это нормально.
Насколько я понял, описываемое решение применяется в случаях, когда 16 или более прерываний в секунду (раз в 64 мс) - это слишком часто. Я с такими случаями не сталкивался, но исключить их возможность не могу.
Прерывания раз в час (или раз в 71 минуту) уж точно навредить не могут, поэтому просто старшие 32 бита счетчика храним в памяти и оперируем 64-битным значением, которое за время существования нашего МК точно не переполнится.
Если же прерывания по переполнению таймера раз в 64 мс допустимы, то можно использовать 16-битный таймер и тоже 32 бита счетчика в памяти. 48 бит хватит лет на шесть, так что раз в 5-6 лет надо будет перезагружаться, что выглядит некритичным ограничением.
Не равно. Для C это !=
P.S. Извиняюсь, что не уточнил. Последнее время у меня очень много кода, где <> встречается чаще, чем !=
Читаем старшие 16 бит.
Читаем младшие 16 бит.
Снова читаем старшие 16 бит.
Если п.1<>п.3 и п.2<32768 используем значение из п.1. Во всех остальных случаях - из п.3.
Может сработать некорректно, если между п.1 и п.3 прошло более 32 мс, что уж очень маловероятно.
Идея здравая, плюсую. Но хотелось бы узнать, в каких случаях 20 прерываний в секунду (каждые 50 мс), могут оказать критическое влияние на работу устройства?
Отличие, пожалуй, лишь одно, но принципиальное. Языки общего назначения императивные, тогда как SQL - декларативный.
Универсальность - это хорошо и востребовано. Но любая универсальность - это поиск компромиссов. Поэтому, например, колоночное хранение в PostgreSQL и в ClickHouse - это две разные вещи, имеющие критически важные отличия.
Если упрощённо, то трактором можно копать, но он не конкурент карьерному экскаватору. Трактором можно убирать зерно, но он не конкурент зерноуборочному комбайну.
Поэтому я не против новых возможностей у PostgreSQL, но только до тех пор, пока они являются не основными и их внедрение не влияет отрицательно на основные функции РСУБД.