Melkij

Postgresql требует запуск сервера бинарниками скомпилированными ровно той же самой версии CATALOG_VERSION_NO что и был вызван initdb при инициализации datadir.
CATALOG_VERSION_NO активно изменяется в процессе разработки, никогда - после релиза major версии.

201909212 - заморожен для 12.0
201906161 - относится к 12beta2

Мы не гарантируем что beta версии будут бинарно совместимы с релизом. Если вы по глупости запустили в работу бета версию и теперь хотите оттуда достать данные - соберите и запустите кластер версии 12beta2. Затем pg_dumpall, поставить и инициализировать initdb релизной версии (12.1 сейчас), импортировать дамп туда.

Это вам как администратору должно быть виднее, зачем вам отдельный /home в 5гб и прочие фрагменты, нужны ли они и какого именно нужны размера.

А так чаще на гипервизорах /boot на отдельном разделе raid1, всё же остальное полезное собирается в lvm поверх рейдов (и виртуалкам целиком LV монопольно, а не файлики в ФС). Возможно в разные VG.

Если база большая - pg_upgrade в link mode. В документации шаги вполне описаны. Желательно иметь реплику на всякий случай.
Если база маленькая - pg_dumpall и импортировать в новую версию из дампа. Собственно всё просто: запустить новую базу на отдельном порту, снять дамп, залить дамп, остановить старую базу,, перезапустить новую на нужном порту.

Просто запустить бинарники одной major версии на datadir другой major версии - не получится.

Для обновления в пределах одного сервера нужны бинарники обеих версий СУБД. Инструкцию по установке уже расписал Alexey Dmitriev

не ниже 10.1(на локалке у меня 10.1) или лучше ставить последнюю 12?

10.11 минимум. Нечего тестировать давно закрытые ошибки.

Посмотрите в vgdisplay есть ли Free PE. Если 0 - расширять просто нечем.

Если free есть - то lvresize или lvextend. Затем расширить файловую систему (resize2fs для ext2/3/4 который у вас вероятно и есть)
Если free нет - то необходимо добавлять новый диск или уменьшать другие разделы. Например, /home . Впрочем, судя по его размеру и 45мб занятых - вы разрезали диск неверно для своей задачи (а зачем вообще резали отдельно /var и /home ?). Может лучше будет вовсе перемонтировать раздел с /home куда-нибудь, скопировать в корневой /home данные и удалить этот том полностью.
Если /home вам нужен отдельный - то опять же resize2fs или какая у вас там файловая система стоит. Сжимаете до какого-то размера (если возможно), проверяете что сжалась, затем уменьшаете логический том (lvresize). Имеет смысл запросить resize2fs меньше размера на который хотите уменьшить раздел. затем после lvresize ещё раз вызвать resize2fs и расширить раздел обратно - чтобы случайно не ошибиться на пару мегабайт и не повредить этим файловую систему.

SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.

Труп. Не надо это исправлять.

-depth Process each directory's contents before the directory itself.
The -delete action also implies -depth.

Это просто не тот параметр, который вы искали. Уровни вложенности это -maxdepth и -mindepth. То есть

find -maxdepth 1 -type f

basebackup - это буквально копирование почти всего из PGDATA тупо на уровне файликов.
Строго в один поток. (ну, на самом деле в отдельном потоке walreceiver ещё если wal method выставлен stream)

Смотрите внимательнее куда упираетесь. Диск на чтение откуда снимаете? Диск куда пишете? Сеть? Одно ядро CPU на базе с которой снимаете? На которую пишете?
Несколько гигабит занять в общем-то не проблема.

apt-get install --no-install-recommends libvirt-clients python-libvirt

kvm и qemu в рекомендуемых пакетах упомянуты, установка которых обычно включена

Так у вас под массив и выделена только половина тома.
Выкидываете диск из массива
mdadm /dev/md0 -f /dev/vda
mdadm /dev/md0 -r /dev/vda
переразбиваете диск на всю ёмкость и добавляете обратно
mdadm /dev/md0 -a /dev/vda
Следите за процессом синхронизации, когда закончится повторяете с другим диском.

Впрочем, через parted resizepart должно быть возможно расширить раздел без пересинхронизации массива.

Потом
mdadm --grow /dev/md0 --size=max
resize2fs /dev/md0

И вопрос в сторону: vda/vdb - обычно обозначают виртуалку. Вы уверены, что вам вообще рейд в госте нужен? Обычно рейд на хост-системе делают.

Разница в количестве вопросов. Вернее в приоритете этих вопросов. How the Installer Works, только параметром priority отличается эти пункты меню.

Нужен explain (analyze,buffers), сильно желательно с track_io_timing = on в конфиге.

параметр work_mem на данный запрос не может оказывать почти никакого влияния

Оказывает. Если планировщик решит, что work_mem не хватает - не будет hash join. Для сортировки 27кб, очевидно, без разницы.

Впрочем, зачем вам вообще join подзапроса где одна только группировка подзапроса занимает половину времени ответа? Вам простой exists нужен.

SELECT "t1".* FROM table_1 as t1
where exists (select 1 from table_2 as t2 WHERE t1.primarykey=t2.session)
ORDER BY "starttime" DESC LIMIT 20;

А дальше know your data. Если по starttime DESC быстро находятся нужные exists - будет хорошо. Если exists мало - стоит подумать, а не денормализовать ли этот признак в table_1 с триггером для консистентности в table_2 и частичным индексом по starttime where t2_exists.

Поля session и primarykey в формате uuid

Не очень хорошая идея. Оно и сильно медленнее при сравнении относительно bigint (особенно если речь о varchar, а не uuid типе данных) и из-за случайного распределения несколько сбивает с толку статистику планировщика.