Melkij

libpq умеет асинхронное выполнение запросов в том смысле, что запрос отправляется на выполнение и возвращает управление приложению не дожидаясь окончания выполнения запроса.
Один коннект к базе в один момент времени может выполнять только один запрос. Вы не можете запустить один запрос и не дождавшись окончания его выполнения запустить другой через это же самое соединение. Через другое соединение - можете.

Будут ли запросы в самой базе сериализоваться в очередь либо выполняться параллельно - вопрос к этим самым запросам. Читающие довольно сложно чем-то заблокировать, пишущие чаще могут конфликтовать за блокировки.

Никаких. Совсем никаких. Это штатный вариант работы, есть даже штатная настройка cluster_name, которая будет выводиться в списке процессов для лёгкости идентификации, на какой именно кластер вы смотрите. Для debian/ubuntu - управляется вовсе стандартными штатными утилитами pg_ctlcluster.

Нужны разные datadir и не пересекающиеся сетевые настройки

Нужен опорный список значений и not exists подзапрос. Опорный список можно сделать через generate_series функцию

select n from generate_series(1,11) as n
where not exists (select from tablename where id = n)

Практически буквально так и пишется:

SELECT * from cc_files WHERE lptime < now() - interval '1 hour'

2 млн записей - это такие копейки.
Что-то делают обычно когда проект не влезает в описание "сейчас никаких проблем".

Что основное можно сделать:
покрутить настройки checkpointer (чтобы checkpoint срабатывал реже - резко меньше random i/o, но при крахе база может дольше стартовать), autovacuum (опустить оба scale_factor куда-нибудь в 0.05 - чтобы автовакуум запускался чаще, но делал меньше работы, плюс уменьшить autovacuum_vacuum_cost_delay - это зависит от дисков)
shared_buffers где-то в 25% от объёма RAM
включить pg_stat_statements и поглядывать топ запросов оттуда

У вас просто терминал узкий для вашей выборки.
Широкие результаты часто удобнее читать в широком виде, который переключается с помощью команды \x в psql:

melkij=> select generate_series(1,3);
 generate_series 
-----------------
               1
               2
               3
(3 строки)

melkij=> \x
Расширенный вывод включён.
melkij=> select generate_series(1,3);
-[ RECORD 1 ]---+--
generate_series | 1
-[ RECORD 2 ]---+--
generate_series | 2
-[ RECORD 3 ]---+--
generate_series | 3

Зависит от требований к бекапам.
Если нужен point in time recovery, т.е. возможность восстановить состояние кластера на какую-то произвольную транзакцию - то это pg_basebackup + архив WAL.
Чтобы не собирать конструктор вручную - есть barman. Если бекапить хотите куда-то в s3 - то проще будут wal-e или wal-g
Одну базу в отдельности так бекапить и восстанавливать не выйдет, только весь инстанс целиком. Объём бекапа = объём всего инстанса + объём всех WAL от начала basebackup до нужного момента восстановления, количество wal зависит от вашей пишущей нагрузки.

Если достаточно логических слепков данных, например, ежесуточных - тогда да, pg_dump. Восстановление соответственно только на момент начала снятия дампа.
Типично делается pg_dumpall -g для сохранения глобальных данных кластера - пользователей, tablespace, имён баз и отдельные pg_dump для тех баз которые надо бекапить.
Формат часто custom делается, т.к. он штатно сжимается и позволяет через pg_restore восстанавливать определённые объекты из дампа, а не только всё целиком как текст через psql. Для гигабайтной базы смысла нет, а для баз побольше имеет смысл делать формат directory в несколько потоков.

Для цели резервного копирования вам нужна не вторая база, а само резервное копирование. То есть pg_basebackup и архив WAL с момента старта basebackup до момента на который вы хотите восстановить состояние базы. Посмотрите barman как более готовую штуку для этого. Или wal-e/wal-g, которые проще в настройке сами по себе - если вы бекапитесь куда-нибудь в совместимое с ними место.

Если вам нужно не резервное копирование, а запасная машинка на случай проблем с первой - то вам нужна репликация. Штатная потоковая репликация отличная стабильная штука. Надо пояснять чем отличается резервирование от бекапов?

Писать кодом в две разные базы - как раз идея плохая как для резервирования, так и для бекапов. Записали изменение в одну базу, во вторую не смогли с какой-нибудь мелкой ошибкой вроде сети моргнувшей. Что делать будете? А ничего хорошего. Корректно писать в несколько мест - задача не слишком тривиальная и нужно что-то сочинять, например протокол двухфазного коммита.

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.

Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.

Обычно автоматики нет, и есть детальная инструкция по переключению мастера БД, по которой и в ночи можно переключиться.

Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.

Ошибка в используемой библиотеке. Так запрашивать версию базы нельзя.

Ломается именно на 10 очевидно из-за смены политики нумерации, до 10 было x.y.z, где x.y - major версия, начиная с десятки релизы нумеруются x.y, где major версия только первая цифра. Глупый код пытающийся распарсить номер находит не то что ожидает.

Вероятно, полтора года спустя с релиза postgresql 10.0, библиотеку уже исправили. Хотелось бы надеяться что на использование специально для этого предназначенной current_setting('server_version_num'), а не опять костылём вокруг не предназначенной для того version()
Копать соответственно в сторону обновления версии библиотеки. Если никак - откатываться на postgresql 9.6.

Нужен 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 типе данных) и из-за случайного распределения несколько сбивает с толку статистику планировщика.

Всё ему нравится,

согласованное состояние восстановления достигнуто

начало передачи журнала с главного сервера, с позиции 4A4/E000000 на линии времени 2

База запустилась, репликация запустилась, всё работает.

А вот вам, наверное, не нравится то что база не принимает read only коннекты? Проверьте настройку hot_standby в postgresql.conf, дефолтно выключено.