Полагаю, вы правы, во втором случае заблокируются ровно те записи, которые нужны. Но надо проверить, как оптимизатор строит план по такому кейсу. Как время будет, гляну
Так нам и нужно, чтобы записи блокировались в определённом порядке. В каком порядке потом мы их будем обновлять - уже не важно, ведь они уже заблокированы нами. То есть это решение проблемы дедлоков. А если говорить о том, в каком порядке записи должны отдаваться наружу - то да, тут итоговый ORDER BY нужен. Но, кажется, это уже другая тема
Как раз наоборот. Если бы не работал ORDER BY, заблокировались бы произвольные записи, а не те, что стоят перед OFFSET. Проверьте :)
На самом деле, если бы записи сначала блокировались, а потом сортировались, это было бы серьёзным нарушением логики работы запроса. То есть запрос не выполнял бы команды, которые в нём указаны. Это критическая ошибка так-то, и сообщество никогда не выпустило бы базу с такой ошибкой на прод. Поэтому используйте FOR (NO KEY) UPDATE смело и не переживайте :)
К слову - у нас годами работают запросы, построенные на подобной логике, и ни одного дедлока. А раньше были, до того как её внедрили.
Вдогонку. Видимо, вы переживаете, что оптимизатор перестроит план запроса так, что в результате записи будут заблокированы в другом порядке, а не в том, что указан в ORDER BY. Такого не произойдёт. FOR (NO KEY) UPDATE - команда, через которую оптимизатор "перепрыгнуть" не может, и в результате план запроса с FOR UPDATE может отличаться от запроса без него. Что нам и требуется
Не совсем так. Когда выполняется SELECT...ORDER BY...FOR (NO KEY) UPDATE, он как раз делает то, что нам нужно - сначала отбирает записи в нужном порядке, указанном в ORDER BY, и потом блокирует их в этом порядке. Никакие дополнительные действия вроде LIMIT для этого не требуются. И далее, когда вы будете изменять заблокированные записи, порядок уже будет не важен - ведь записи уже заблокированы в вашей транзакции, только это сделано до UPDATE. И, кстати, если мы хотим зафиксировать результат CTE, можно использовать материализацию.
Относительно избыточных вычислений - тут нужно рассматривать в комплексе. Если у вас будет дедлок, одна из транзакций будет откачена, а вместе с ней и все изменения, возможно, других запросов, если были. И тогда придётся заново выполнять весь метод со всеми его вычислениями. Если же мы уходим от дедлока ценой некоторых дополнительных вычислений (за всё приходится платить...) то в целом мы оказываемся в выигрыше, плюс повышается стабильность системы в целом
Сценарии схематичные, конечно. В реальности мы перед обновлением или добавлением записей сначала формируем требуемые данные в отдельных CTE, в которых присутствует ORDER BY и FOR UPDATE. И потом уже по предварительно заблокированным записям выполняем UPDATE, либо INSERT в установленном порядке. В результате имеем добавление/изменение с фиксированным порядком записей. Операций несколько больше, зато без взаимоблокировок.
Используем READ COMMITTED. Это удобный уровень изоляции, потому что если встанем на заблокированную запись, PostgreSQL перед её изменением перечитает её, когда её отпустит конкурирующая транзакция. По большому счёту это соответствует нашим задачам.
По поводу LIMIT - да, мы стараемся не допускать слишком масштабного изменения записей в одной транзакции. Тут можно не только LIMIT-ом регулировать, но и на уровне БЛ, например, решать, сколько записей на обновление отправлять в запрос. Поэтому есть несколько вариантов.
Он на вход принимает четыре сигнала - два 4-20 мА, 0-5В, и 0-10В. И отдаёт их значения через RS485. Модуль действительно хороший, и я приобрёл себе такой именно для ситуаций, когда нужно будет передавать нечто аналоговое в цифре. Но в случае моего контроллера всё вполне уложилось в обработку аналогового сигнала, поэтому на том и остановился
Расстояние около 10 м, что в разумных пределах, учитывая то, что это датчик тока. Конечно на больших расстояниях лучше использовать сразу в цифре, это бесспорно, но в моём случае действительно получается примерно схожая точность
Там банально порты кончились. Осталась одна свободная ножка, но на ней висит внутренний термометр платы микроконтроллера, который я тоже планирую прикрутить в интеграцию. А DAC управляется по I2C
Раз на выходе модуля трансформатора тока есть конденсатор, то это получился выпрямитель с удвоением напряжения (Латура-Дилона). Просто конденсатор не попал на крупно-блочную схему.
Да, это оно и есть. Спасибо за то, что написали, как называется этот эффект. Я на просторах Интернета нашёл схему этого модуля (прилагаю). После прочтения схемы как раз и реализовал то, что на крупно-блочной схеме показано (после предварительной проверки, само собой).
Принципиальная схема модуля zmct103c
Реле с контролем перехода напряжения через ноль - не лучший выбор для индуктивной нагрузки. Через полпериода в цепи возникнет ток, в разы превышающий номинальный. Моторы и трансформаторы - лучше включать на максимуме напряжения
Полностью согласен. К слову, это была одна из причин, почему силовой модуль решил оформить отдельно - мало ли вдруг придётся заменить силовые реле (симисторы) или полностью его перепроектировать. Разработчиков твёрдотельного реле с zero-cross понимаю, так как нулевое напряжение намного проще диагностировать и на него среагировать, чем на максимум напряжения. Пока понаблюдаю, и если уж совсем плохо будет, реализую по-другому
Как ни странно, не сильно много времени потратил. В деньгах сказать трудно, потому что многое использовал из того, что было ранее. Плюс делал скорее в удовольствие, без оглядки на сроки/дедлайны и прочее, и в свободное время. Это всё создало комфортную атмосферу для проектирования и разработки.
Вариант с датчиком с RS485 тоже хороший. У меня даже лежит такая платка с RS485-интерфейсом и MODBUS RTU протоколом, а на вход принимает сигналы с двух датчиков токовой петли. И я даже интегрировал её в HomeAssistant. Но позже решил всё же двигаться в сторону контроллера, поскольку хотелось завязать всю логику обработки состояний водяной системы на контроллер. Здесь нужно смотреть, как удобнее сделать в каждом конкретном случае.
Да, по факту гидростатический датчик и есть датчик давления. Вообще говоря, на данный момент из известной мне практики, для подобных систем в основном используются два типа датчиков - гидростатические и ультразвуковые. Гидростатические в размещении проще, и там как раз удобно использовать предложенный вами способ подключения через отвод и кран
Не измерял, но думаю, как обычно - раза в 4 больше номинального. Сказать по-честному, этот момент меня волновал больше всего. Поэтому перед тем как запустить, я погонял запуск насосов на модуле, заранее будучи готовым к потере твёрдотельных реле. Отработал около ста пусков. Ни одно реле не сгорело. Поэтому я решился на их использование, но запасной модуль всё же лежит рядом... Полагаю, что не последнюю роль в этом играет zero-cross и то, что токи кратковременные. В общем, понаблюдаю. В худшем случае заменить на обычные реле всегда успею
Не совсем так. Они условно "подпирают снизу" сигнал (на выходе датчика — переменное напряжение после проходного конденсатора). Это интересный эффект, если есть желание - проверьте сами. Я сам сначала проверил осциллографом, и только после этого реализовал
Ответ прост: бочка делалась во времена, когда сильно воровали + часто отключали электричество. И бочка в таких обстоятельствах реально выручала. Высоты водяного столба 5,5 м от бочки до крана было достаточно для комфортного пользования водой. Электричество и сейчас нет-нет да отключают. Поэтому внешние факторы тут играют роль до сих пор
Полагаю, вы правы, во втором случае заблокируются ровно те записи, которые нужны. Но надо проверить, как оптимизатор строит план по такому кейсу. Как время будет, гляну
Так нам и нужно, чтобы записи блокировались в определённом порядке. В каком порядке потом мы их будем обновлять - уже не важно, ведь они уже заблокированы нами. То есть это решение проблемы дедлоков. А если говорить о том, в каком порядке записи должны отдаваться наружу - то да, тут итоговый ORDER BY нужен. Но, кажется, это уже другая тема
Как раз наоборот. Если бы не работал ORDER BY, заблокировались бы произвольные записи, а не те, что стоят перед OFFSET. Проверьте :)
На самом деле, если бы записи сначала блокировались, а потом сортировались, это было бы серьёзным нарушением логики работы запроса. То есть запрос не выполнял бы команды, которые в нём указаны. Это критическая ошибка так-то, и сообщество никогда не выпустило бы базу с такой ошибкой на прод. Поэтому используйте FOR (NO KEY) UPDATE смело и не переживайте :)
К слову - у нас годами работают запросы, построенные на подобной логике, и ни одного дедлока. А раньше были, до того как её внедрили.
Вдогонку. Видимо, вы переживаете, что оптимизатор перестроит план запроса так, что в результате записи будут заблокированы в другом порядке, а не в том, что указан в ORDER BY. Такого не произойдёт. FOR (NO KEY) UPDATE - команда, через которую оптимизатор "перепрыгнуть" не может, и в результате план запроса с FOR UPDATE может отличаться от запроса без него. Что нам и требуется
Не совсем так. Когда выполняется SELECT...ORDER BY...FOR (NO KEY) UPDATE, он как раз делает то, что нам нужно - сначала отбирает записи в нужном порядке, указанном в ORDER BY, и потом блокирует их в этом порядке. Никакие дополнительные действия вроде LIMIT для этого не требуются. И далее, когда вы будете изменять заблокированные записи, порядок уже будет не важен - ведь записи уже заблокированы в вашей транзакции, только это сделано до UPDATE. И, кстати, если мы хотим зафиксировать результат CTE, можно использовать материализацию.
Относительно избыточных вычислений - тут нужно рассматривать в комплексе. Если у вас будет дедлок, одна из транзакций будет откачена, а вместе с ней и все изменения, возможно, других запросов, если были. И тогда придётся заново выполнять весь метод со всеми его вычислениями. Если же мы уходим от дедлока ценой некоторых дополнительных вычислений (за всё приходится платить...) то в целом мы оказываемся в выигрыше, плюс повышается стабильность системы в целом
Сценарии схематичные, конечно. В реальности мы перед обновлением или добавлением записей сначала формируем требуемые данные в отдельных CTE, в которых присутствует ORDER BY и FOR UPDATE. И потом уже по предварительно заблокированным записям выполняем UPDATE, либо INSERT в установленном порядке. В результате имеем добавление/изменение с фиксированным порядком записей. Операций несколько больше, зато без взаимоблокировок.
Используем READ COMMITTED. Это удобный уровень изоляции, потому что если встанем на заблокированную запись, PostgreSQL перед её изменением перечитает её, когда её отпустит конкурирующая транзакция. По большому счёту это соответствует нашим задачам.
По поводу LIMIT - да, мы стараемся не допускать слишком масштабного изменения записей в одной транзакции. Тут можно не только LIMIT-ом регулировать, но и на уровне БЛ, например, решать, сколько записей на обновление отправлять в запрос. Поэтому есть несколько вариантов.
Обычно для этого пользуемся SELECT...FOR UPDATE, там порядок блокировки можно указать
Интересно, а есть подробный сценарий? Как боретесь?
Вдогонку. Нашёл на Озоне вот такой модуль
https://www.ozon.ru/product/eletechsup-modul-4-20ma-dlya-sbora-signalov-napryazheniya-rs485-modbus-rtu-dlya-plk-1898777565/
Он на вход принимает четыре сигнала - два 4-20 мА, 0-5В, и 0-10В. И отдаёт их значения через RS485. Модуль действительно хороший, и я приобрёл себе такой именно для ситуаций, когда нужно будет передавать нечто аналоговое в цифре. Но в случае моего контроллера всё вполне уложилось в обработку аналогового сигнала, поэтому на том и остановился
Расстояние около 10 м, что в разумных пределах, учитывая то, что это датчик тока. Конечно на больших расстояниях лучше использовать сразу в цифре, это бесспорно, но в моём случае действительно получается примерно схожая точность
Там банально порты кончились. Осталась одна свободная ножка, но на ней висит внутренний термометр платы микроконтроллера, который я тоже планирую прикрутить в интеграцию. А DAC управляется по I2C
Спасибо! Примерно месяц на всё про всё. Начал в середине сентября, в середине октября уже всё работало
Да, это оно и есть. Спасибо за то, что написали, как называется этот эффект. Я на просторах Интернета нашёл схему этого модуля (прилагаю). После прочтения схемы как раз и реализовал то, что на крупно-блочной схеме показано (после предварительной проверки, само собой).
Полностью согласен. К слову, это была одна из причин, почему силовой модуль решил оформить отдельно - мало ли вдруг придётся заменить силовые реле (симисторы) или полностью его перепроектировать. Разработчиков твёрдотельного реле с zero-cross понимаю, так как нулевое напряжение намного проще диагностировать и на него среагировать, чем на максимум напряжения. Пока понаблюдаю, и если уж совсем плохо будет, реализую по-другому
Согласен, 4-20 мА действительно удобный интерфейс. Плюс позволяет сразу диагностировать обрыв линии, если ток нулевой
Как ни странно, не сильно много времени потратил. В деньгах сказать трудно, потому что многое использовал из того, что было ранее. Плюс делал скорее в удовольствие, без оглядки на сроки/дедлайны и прочее, и в свободное время. Это всё создало комфортную атмосферу для проектирования и разработки.
Вариант с датчиком с RS485 тоже хороший. У меня даже лежит такая платка с RS485-интерфейсом и MODBUS RTU протоколом, а на вход принимает сигналы с двух датчиков токовой петли. И я даже интегрировал её в HomeAssistant. Но позже решил всё же двигаться в сторону контроллера, поскольку хотелось завязать всю логику обработки состояний водяной системы на контроллер. Здесь нужно смотреть, как удобнее сделать в каждом конкретном случае.
Да, по факту гидростатический датчик и есть датчик давления. Вообще говоря, на данный момент из известной мне практики, для подобных систем в основном используются два типа датчиков - гидростатические и ультразвуковые. Гидростатические в размещении проще, и там как раз удобно использовать предложенный вами способ подключения через отвод и кран
Не измерял, но думаю, как обычно - раза в 4 больше номинального. Сказать по-честному, этот момент меня волновал больше всего. Поэтому перед тем как запустить, я погонял запуск насосов на модуле, заранее будучи готовым к потере твёрдотельных реле. Отработал около ста пусков. Ни одно реле не сгорело. Поэтому я решился на их использование, но запасной модуль всё же лежит рядом... Полагаю, что не последнюю роль в этом играет zero-cross и то, что токи кратковременные. В общем, понаблюдаю. В худшем случае заменить на обычные реле всегда успею
Не совсем так. Они условно "подпирают снизу" сигнал (на выходе датчика — переменное напряжение после проходного конденсатора). Это интересный эффект, если есть желание - проверьте сами. Я сам сначала проверил осциллографом, и только после этого реализовал
Грамотный подход, понравился. И интерфейс у датчика понравился. Взял идею на карандашик, может в будущих проектах сделаю что-то подобное. Спасибо!
Ответ прост: бочка делалась во времена, когда сильно воровали + часто отключали электричество. И бочка в таких обстоятельствах реально выручала. Высоты водяного столба 5,5 м от бочки до крана было достаточно для комфортного пользования водой. Электричество и сейчас нет-нет да отключают. Поэтому внешние факторы тут играют роль до сих пор