Melkij

У вас просто терминал узкий для вашей выборки.
Широкие результаты часто удобнее читать в широком виде, который переключается с помощью команды \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, дефолтно выключено.

Передайте pg_class.oid и всё.

pg_size_pretty(pg_table_size(с.oid)) AS size,
pg_size_pretty(pg_indexes_size(с.oid)) AS idxsize,
pg_size_pretty(pg_total_relation_size(с.oid)) as "total"

Если загляните в определение pg_tables - то увидите, что это view от pg_class с фильтром relkind = 'r'. То есть объединение с pg_tables довольно лишнее.

Настроек у него никаких, поэтому достаточно проверить, что он загружен, т.е. упомянут в
show shared_preload_libraries;

copy можно указать поля таблицы для заполнения, то есть в таблице может быть полей больше, чем в источнике данных. Такие дополнительные поля должны иметь значение по-умолчанию или быть null

COPY test (field1, field2, ...) FROM 'test.csv' DELIMETR ',' CSV;

Синтаксиса для пропуска полей не предусмотрено.

pga_hba.conf можете редактировать как и чем угодно, это не имеет отношения к базе (ну разве вы только руками переопределили hba_file).
А файл правил авторизации pg_hba.conf необходимо редактировать текстовым редактором, желательно каким-то адекватным который не будет заниматься самодеятельностью с правами, именами, владельцами и содержимым файла. После внесения правок в pg_hba необходимо скомандовать reload базе.
select pg_reload_conf();
Запросом от суперпользователя предпочтительнее, т.к. не зависит от платформы.

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

Единожды хэшированный согласно способу аутентификации md5 протокола libpq.

Ну и конечно надо понимать, что меняется и где именно. pg_hba обрабатывается по порядке сверху вниз и правило вполне можно указать даже банально не там где нужно.
Плюс при reload смотрите в лог, сообщения об ошибке формата там будут.