Melkij

Вам нужен check constraint.

XOR в postgresql вроде нет, так что показывать на пальцах:

alter table tablename add constraint tablename_p1_xor_p2 check((p1 is null and p2 is not null) or (p2 is null and p1 is not null));

В /proc/mdstat только дисковые массивы, активные сейчас. И, опять же, только тома входящие в этот массив. Если вы делали странное (а вы делали странное) - то ядро вполне резонно решило, что желает пообщаться с оператором.

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

Java - это такой специальный язык для генерации километровых backtrace...

Почему получив null value in column violates not-null constraint вы решили, что у вас проблема с подключением к СУБД? Вы пытаетесь вставить NULL в поле отмеченное как NOT NULL. Судя по тексту запроса - у вас не указано default значение для этого поля.

Нет, гарантии нет. Менять привычный 5432 порт у сообщества причин нет. Теоретически поменять дефолтный порт можем, это не так сложно технически - но зачем? Мы не гарантируем совместимость с последующими версиями и вполне можем решить что-нибудь сломать нужное, если сообщество согласится что оно того стоит. Гарантий не дадим, но вполне можно рассчитывать что будет 5432 ещё очень долго использоваться по умолчанию, нет причин его менять и есть веские причины его не менять.

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

--with-pgport=PORTNUM set default port number [5432]

Пока он как-то сам выбирает порт

PostgreSQL не занимается таким. Просто откажется стартовать если не удастся открыть сокет. Номер порта не менялся очень давно, если менялся вообще хоть когда-нибудь от самого основания ещё post-ingres в 198х годах.

Вот сторонние скрипты - те могут иметь какую-нибудь такую логику. Например, пакеты debian/ubuntu при вызове pg_createcluster попробует прописать в конфиге ближайший свободный порт начиная с 5432. Никакой зависимости от версии СУБД нет. Нужен новый кластер? Ок, возьмём ближайший свободный порт и настроим на использование его.

Делаете бекап, конвертируете, проверяете.
Так-то триггеры живут уровнем выше storage engine и задеть не должны.

PS: и стоит ещё раз внимательно подумать, точно ли хорошая идея менять транзакционный innodb на какую-то кучу бинарного мусора. Если вы понимаете, что транзакционность - это не только про слова begin/commit.

postgres=# CREATE DATABASE joba_finder;
CREATE DATABASE
postgres=# CREATE USER jf_user WITH PASSWORD 'qwerty';
CREATE ROLE
postgres=# \l joba_finder 
                               Список баз данных
     Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   | Права доступа 
-------------+----------+-----------+-------------+-------------+---------------
 joba_finder | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | 
(1 строка)

postgres=# GRANT ALL PRIVILEGES ON DATABASE joba_finder to jf_user;
GRANT
postgres=# \l joba_finder 
                                   Список баз данных
     Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
-------------+----------+-----------+-------------+-------------+-----------------------
 joba_finder | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =Tc/postgres         +
             |          |           |             |             | postgres=CTc/postgres+
             |          |           |             |             | jf_user=CTc/postgres
(1 строка)

postgres=# select version();
                                                version                                                 
--------------------------------------------------------------------------------------------------------
 PostgreSQL 11.2 (Debian 11.2-2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-2) 8.3.0, 64-bit
(1 строка)

Just works. Настройками это не регулируется, так что проверяйте что вы делаете не так. Может быть не коммитите транзакцию с grant? Не знаю.

Не заметил:

joba_finder-# \l

Внимание на -# так где должен быть =# - метка указывает, что вы начали писать запрос, но не завершили его. psql команды вроде \l при этом всё ещё обрабатываются.

postgres=# select
postgres-# \l joba_finder 
                                   Список баз данных
     Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
-------------+----------+-----------+-------------+-------------+-----------------------
 joba_finder | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =Tc/postgres         +
             |          |           |             |             | postgres=CTc/postgres+
             |          |           |             |             | jf_user=CTc/postgres
(1 строка)

postgres-# 1;
 ?column? 
----------
        1
(1 строка)

Как пример psql команды в середине написания select 1;

https://wiki.php.net/rfc/pcre2-migration

The userland code is unaffected

Ключевые отличия - изменения C API. Потому смена major версии библиотеки.

Сложно сказать с не воспроизводимым примером кода. Впрочем легко заметить, что сейчас ваш метод _query строго одноразовый. На повторный запуск этого метода (в контексте одного объекта) вы получите такую ошибку. Потому что curl_close закрывает ресурс, но переменная остаётся типа ресурс и потому не отвечает условию !$this->_ch

Штука называется Protocols and Wrappers, могут быть даже самописные.
Ровно та же самая вещь, почему file_get_contents умеет делать http запросы.

Возможно ли не встравлять в таблицу записи, которые уже присутствуют в таблице?

Возможно. Если вы этим знанием свой предметной области поделитесь с СУБД и создадите уникальное ограничение. А скорей всего это вовсе натуральный первичный ключ.

on conflict работает как ни удивительно при конфликте уникальности. Поэтому пока у вас никто не гарантирует уникальность данных - on conflict ничего не сделает.

Попробуйте так:

SELECT Prop.*, coalesce("counters".countAllUnits, 0) AS "countAllUnits", coalesce("counters".countVacantUnits, 0) AS "countVacantUnits"
                    FROM "Property" AS Prop
                    INNER JOIN LATERAL
                    (
                     SELECT COUNT(*) AS countAllUnits,
count(*) filter(where "Unit".status = 'Vacant') as countVacantUnits
                     FROM "Unit"
                     WHERE Prop."id" = "Unit"."propertyId"
                    ) AS "counters" ON true
                    WHERE  Prop."userId" IN (
                          SELECT id FROM "User" WHERE  "companyId" = 200001
                    )
                    ORDER BY Prop."userId" ASC LIMIT 10 OFFSET 0

Ожидание: раннее отсечение limit 10 и nested loop именно от них.

Вы с какой-то очень не той стороны хотите подойти к задаче. Вопрос на который надо искать ответ - зачем вы это хотите?

В нормальном виде у вас вообще нет такой задачи уже на уровне прав - DDL запрещены вовсе для пользователя приложения. А для людей - решается не техническими средствами, а организационно. То есть к проду в любое время суток нет доступа на изменение схемы людьми (а вообще-то и на чтение людьми тоже, для людей доступ к не боевой реплике), которые не отвечают за последствия своих действий. А специалистам, у которых доступ должен быть - чинить препятствия странно, хоть днём, хоть тем более ночью (когда критичные вещи и могут выкатываться).

Впрочем, event triggers могут быть ddl_command_start для ряда create команд.

Но первичный ключ является обязательным для каждой таблицы

С точки зрения реляционной теории и нормальных форм в частности.

С точки зрения SQL - не обязателен. Таблица может не объявлять первичный либо даже какой-то уникальный ключ. Дальше - детали реализации.

В PostgreSQL никакой даже суррогатный первичный ключ в этом случае создаваться не будет. Адресация строк в PostgreSQL выполняется по TID (tuple ID) - физическому адресу строки в датафайле (и потому TID уникален в таблице), в том числе при поиске по первичному ключу. Но TID - не индекс, никак не связан с хранимыми данными и не накладывает каких-либо ограничений на данные.