dyndns без белого IP бесполезен. dyndns поможет для белого динамического IP, который меняется по усмотрению провайдера, но маршрутизирует честно трафик из глобальных интернетов на ваш маршрутизатор.
Куда чаще пользователь за провайдерским NAT'ом, который не будет маршрутизировать входящий трафик вообще.
Дополнительная услуга провайдера - речь про белый статический IP, то есть за вашим договором закрепляется некий IP, который будет изменяться только в исключительных случаях. И, что ещё имеет смысл уточнить у провайдера, не фильтрует ли он какие-то порты даже при аренде статического IP.
вопрос ведь в допусках на всём диапазоне нагрузки и пульсациях. Я не удивлюсь, если конкретный ноутбук не увидит ничего плохого от питания в диапазоне этак 10-15В как допустимое отклонение от 12В. А вот HDD так питать... Насколько далеко от требуемого стандартом 12В +-5% приемлемо для входа на конкретных HDD?
если ноутбучные имеют выходное напряжение - 12 вольтное, то используй напрямую.
я бы хорошо посомневался в стабильности питания ноутбучных БП... Они ведь заведомо предполагают DC-DC за собой на входе самого ноутбука и из-за этого предположения могут сильно упрощать схемотехнику.
Читайте внимательнее. Документация ничего не сказала о том, что вам нужно создавать отдельный уникальный индекс.
unique constraint как требуемая по SQL spec сущность реализована как уникальный btree в postgresql. Не может быть unique constraint без уникального индекса. Создавать же отдельный индекс идентичный существующему unique constraint не только малополезное занятие, но и вредное.
В дополнение, в определение индекса добавлено поле unix_time_check в части INCLUDE.
По моему опыту, без этих индексов цена select`а взлетает в небо
не множественное, а единственное число. Один индекс нужен, второй бесполезен и вреден.
как менялась оценка и при каких конкретно stats target'ах?
покажите select * from pg_stats where tablename = 'friends_info' and attname = 'user_id' \gx
посмотрите внимательно на сами данные. Ошибка не от синтаксического разбора запроса, а именно конкретного значения. jsonb валидирует входящие данные, чтобы это был действительно валидный json, а не просто какой-то текст. Из лога базы можете достать конкретное переданное значение.
mysql исторически приводит в синтаксической ошибке место после которого парсер перестал понимать что происходит. При том, что весьма примечательно, это оказался символ окончания запроса ;
Смотрите на предшествующий текст запросов. Или приведите в вопросе реальный запрос, который даёт такую ошибку.
таблицы без первичного ключа в большинстве случаев это ошибка разработчика схемы данных. Но в остальном обычная табличка, может так и существовать в postgresql без первичного ключа.
это нормальное состояние на высоколатентных дисках. Смириться или переезжать на нормальные диски.
"писать большими блоками"
у вас обновилась одна строка таблицы и соответственно к определению этой таблицы допустим пять индексов. Разумеется, это 6 разных блоков в разных местах. Ну и как вы их запишете одним большим блоком, ммм?
вы бы хоть написали в вопросе, что это вообще дисковая полка. Там-то причин куда больше бывает. По вопросу выглядит, что вы перетыкаете кабель напрямую от atx блока питания напрямую к диску...
Куда чаще пользователь за провайдерским NAT'ом, который не будет маршрутизировать входящий трафик вообще.
Дополнительная услуга провайдера - речь про белый статический IP, то есть за вашим договором закрепляется некий IP, который будет изменяться только в исключительных случаях. И, что ещё имеет смысл уточнить у провайдера, не фильтрует ли он какие-то порты даже при аренде статического IP.