Melkij

Вы в after insert триггере на табличке со странным названием lechenie выполняете безусловный insert в эту же самую таблицу. Вопрос к вам: почему вы в результате ожидаете что-то кроме бесконечной рекурсии?

Следовать PSR и вынести объявление класса в отдельный файл по ожидаемому пути PSR-4 (или PSR-0).

В postgresql все текстовые типы следуют кодировке базы. case insensitive utf8 в pg не предусмотрено.
Поэтому если у вас база в utf8 - то "STEM" varchar(50) not null
Если база не в utf8 - не надо так делать.

Задача минимумум: прочитать файлы, содержащиеся в образе.

mount -o loop,offset=$((512*start_сектор_нужного_раздела)) file mountpoint
или losetup с параметром модуля ядра loop.max_part в какое-нибудь адекватное значение - тогда будут loop устройства с разделами как обычное блочное устройство.

Задача максимум: и прочитать файлы и засунуть виртуалку в Proxmox, в качестве хранилища использующий LVM на CephFS.

Сделать LV по меньшей мере такого же размера, скопировать весь файл поблочно через dd

Повесить дополнительный IP на интерфейс, перевесить веб-сервер туда и обратиться к этому адресу.
Или банально воткнуть $_SERVER['REMOTE_ADDR'] = 'any another ip'; где-нибудь до проверки. $_SERVER не защищён от записи. Только не забыть удалить перед коммитом.

Да, будут потеряны.

Во время переезда на массив часто массив инициализируют деградировавщим:
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/hdc1
Затем копируют на него данные и потом добавляют недостающий диск.

select json_agg(tablename) from tablename;
Всё. Получите json массив.

Недостаточно данных. Разные storage engine будут вести себя разным образом. Для транзакционных storage будут иметь значение уровень изоляции транзакции и собственно как именно реализована транзакционная обработка в обоих приложениях.

innodb, read commited, транзакционная работа писателя: читатель увидит версию данных как будто писатель ничего ещё не делал.
innodb, read commited, нетранзакционная работа писателя/autocommit - читатель увидит какой-то промежуточный результат, что-то обновлено, что-то ещё нет.
myisam - подождёт завершение пишущего запроса (только мешающего запроса! Следующий пишущий запрос постоит подождёт завершение читающего запроса), прочитает текущее состояние

Подводный камень очевиден - указанной командой вы потеряли все данные. Ну или получите отлуп, если повезёт.
Не стесняйтесь поискать, вопрос миграции имеющейся системы на рейд - штука распространённая. Хотя несколько геморройная - сильно зависит от требований к даунтайму.

Суть для вашего случая: разметить sdb, инициализировать как degraded массив:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb5
Перенести всё полезное с sda на sdb, поправить загрузчик, перезагрузиться с рейда, добавить разделы sda в соответствующие массивы.
Инициализировать массив напрямую на устройство, а не разделы, возможно, но с этого устройства нельзя будет загружаться.

Разные фокусы с переносом всего полезного. Системный раздел может быть проще через dd скопировать (но раздел на sdb должен быть чуть больше, там ещё mdadm суперблок в 2048 секторов)
/home - начальную копию в 2-3 прохода rsync'ом, затем перемонтировать в ro и ещё один rsync.

Всё очевидно:
суперпользователь базы - лицо доверенное и база доверяет этому пользователю. И суперпользователь множеством хитрых и не очень способов способен сделать с сервером на котором запущена база всё на что хватит прав у пользователя, от которого запущен postgres.
Например, запустить любую произвольную команду даже простой и очевидной командой copy, не говоря уже о каких-то извращениях.

Конкретная атака по-видимому уже разобрана и описана вот тут: https://habrahabr.ru/post/351452/

Никогда не используйте trust, уж тем более в мир. В нормальном состоянии база вообще не должна быть открыта в мир.

Вы предполагаете слишком умную логику для глупой функции.
https://github.com/php/php-src/blob/PHP-7.2/ext/st...
var_export пытается вывести строку в одинарных кавычках, чтобы в ней не осуществлялись подстановки спецсимволов и другого счастья. Но null-байт поэтому же в одинарных кавычках вывести нельзя. Поэтому все \0 заменяются на ' . \"\\0\" . '
В предельном случае получаются как раз одинарные кавычки по краям результирующей строки и ' . \"\\0\" . ' в качестве основных данных. А проверять предварительно, что у нас всего-то и есть \0 в строке -- слишком частный случай.

2. Нужно ли включать order by в таких огромных таблицах?

Не зависит от размера базы.
Или у вас есть order by и поведение ожидаемое или у вас нет order by и СУБД имеет полное право на каждый запрос выдавать любые подходящие под фильтр данные в любом порядке.
Запрос выдающий неправильные данные обычно никому не нужен, даже если он и быстрый.

offset для пагинации вообще вещь неуклюжая. https://use-the-index-luke.com/no-offset
Быстрая пагинация - это передача уникального идентификатора, последнего на просматриваемой странице. Т.е. запрос на выборку следующих 100 записей начиная после такого-то id.
Бонусом консистентное поведение, если, например, что-то из строк предыдущей страницы удалили. Оффсет тупо потеряет строку из выборки и пользователь может не найти то что искал.

3. Ну типа берем сначала вытаскиваем данные с одной таблицы, потом по результату смотрим id, по нему вытаскиваем данные связанные со второй таблицы, затем смотрим новый результат и так же вытаскиваем с третьей. Получается в бд не будет строится огромная временная таблица из трех больших таблиц.

Вы изобрели то что делает джойн. База в общем случае его сделает лучше.
Будет ли огромная временная таблица - смотрите план.