посмотрите что dmesg про них писал. Сюда влезли ручки всякого systemd и сломали ранее исправно работавшее именование интерфейсов через udev при конфликтующих именах, когда надо поменять местами два имени между собой. Помогает использование имён не ethX, а, например, NAME="ethbond0" или NAME="ethlan"
NEW и OLD в триггерах - это предварительно объявленные переменные типа record.
select from не предполагает использование переменной в from и пытается искать таблицу/view/etc с таким именем.
Что означает "Перестаёт работать"? Если отказывается стартовать, то с какой формулировкой. Если стартует, то, опять же, что в логах и в чём выражается "Перестаёт работать"
Security through obscurity мало того что бессмысленный, так вы сами себя им и запутали.
Не понятно почему два разных списка.
Потому что это два разных postgres'а.
Создавал базы так:
Соответственно, не в том postgresql о котором думали, но не проверили, к какому именно подключаетесь.
Развели бардак и закономерно потеряли что у вас где. Соберите бардак воедино в нормальный 5432, а безопасность обеспечить нормальным закрытием порта через firewall.
Плюс revoke all on database .. from public;
Где именно и как именно создали базы? Внимание на себя обращает нестандартный порт. Значит чего-то нестандартного навертели уже. И стоит начать с вопроса, а сколько экземпляров postgresql вообще запущено, не запутались ли сами в том что уже навертели.
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, а не просто какой-то текст. Из лога базы можете достать конкретное переданное значение.
