Melkij

Как выгрузить из бэкапа нескольких БД одну необходимую?

бэкап всех БД - all_databases.sql

Никак.
Либо идти руками и текстовым редактором доставать именно нужное.

-U - существующий в postgresql пользователь, от имени которого можно зайти сейчас. А не после разворачивания бекапа. Для бекапа всего кластера очевидно понадобится суперпользователь, postgres или pgsql обычно.
-d имя базы данных, а не таблицы. База так же должна уже существовать, чтобы можно было подключиться к pg.

Потому что не был вызван nextval. За ненадобностью.
Раз не нужно было генерировать новое значение, то зачем его дёргать зря?

Если в лоб:

select ... from events where exists (
    select 1 from generate_series(events.start_date, :target_end_date, events.repeat) as d(rep_date) 
    where rep_date between :target_date and :target_end_date
);

Как сделать быстро сходу не сообразил.

гарантирует ACID где буква «C» означает Consistency — Согласованность.

В пределах одного кластера postgresql. Т.е. одного сервера.

возможна ли ситуация когда ключи «X» и «Y» уже реплицированны на сервер «B», но еще не реплицированны на сервер «C»? При асинхронной репликации?

By design. Потому это и названо асинхронной репликой. Между коммитом на мастере и приходом каждого отдельного асинхронного слейва в это состояние всегда будет какой-то временной лаг.
Но timeline один на всех, т.к. его ведёт мастер. Ситуация, что на B записан только X, а на C только Y - исключена.

Синхронная реплика - мастер не ответит клиенту "записано" пока не получит отклик от синхронных реплик из synchronous_standby_names, что те получили эти wal (дефолт, гарантирует, что данные есть минимум на двух машинах и при внезапном сбое вы их не потеряете), применили эти изменения (synchronous_commit=remote_write соответственно два кластера postgresql синхронны. Из-за CAP теоремы теоретически возможно, что при сбое мастера на слейве эта транзакция будет уже записана, а на мастере значится как прерванная. Не знаю, что именно по этому поводу сделано).
Внимание, что при потере работоспособности синхронной реплики мастер будет доступен только на чтение. Все пишущие транзакции будут ждать возвращения синхронной реплики.

Гарантируется ли согласованность в системе из нескольких реплицируемых серверов?

Смотря чем вам допустимо жертвовать для этого. См. CAP теорему.

Это, разумеется, справедливо только для встроенной бинарной потоковой репликации WAL. Логическая в 10 будет жить по своим особым правилам, как и сторонние триггерные решения.

sudo rm -rf /var/lib/postgresql

Это был home dir пользователя, а не каталог кластера. Каталог кластера в дефолтной поставке в /var/lib/postgresql/версия_pg/ещё_одна_директория_main_или_base

sudo mkdir /media/ad/data/bd1c

Допустим.

su postgres -c '/usr/lib/postgresql/9.6/bin/initdb -D media/ad/data/bd1c --locale=ru_RU.UTF-8'

Внимание на относительный путь. Я не уверен, где в итоге initdb пытался сделать базу.

привел к виду
data_directory = '/var/lib/pgsql'

? Откуда это здесь взялось?

какой из postgresql.conf главнее

Тот, который указан в аргументах запуска postgres. Явным образом через -c config_file либо находящийся в PGDATA в случае отсутствия аргумента с именем конфига.

Точно про актуальную монгу сказать что-то затрудняюсь.
Про версию постарше цитата про вторую версию монги

MongoDB v2.0 will consider a write to be complete, done, finito as soon as it has been buffered in the outgoing socket buffer of the client host.

Отвечает "записано", когда данные даже не покинули машину клиента, не то что записаны хоть куда-нибудь.
С таким подходом задумывались ли авторы над потерей данных вообще и исправлено ли сейчас?

и тут я вспомнил что у postgresql есть параметр wal_writer_delay = 200ms, что-же получается и у postgresql может быть такая ботва что клиент думает что строка сохранена а все накрылось до сброса журнала на диск???

Если вы намеренно выкрутили гайку synchronous_commit.

fsync - это очень дорого. Даже на SSD.
Поскольку это дорого, делаются какие-нибудь фокусы. Магнитные диски ненавидят случайную запись и куда лучше относятся к последовательной. Поэтому и тут тоже придумывают какие-то фокусы.
В итоге postgresql (если вы сами не отстрелили себе ноги) пишет wal в память, отдельный процесс каждые wal_writer_delay просыпается, сбрасывает на диск накопленные wal и отмечает, в какой позиции wal гарантированно доехал до диска fsync. Поскольку synchronous_commit включен, то перед ответом клиенту "записано" воркер ждёт, пока его данные не будут записаны на диск. После этого отвечает приложению "записано".
https://www.postgresql.org/docs/current/static/run...

synchronous_commit (enum) Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a "success" indication to the client

Ускорить можно вот такой милой рекурсивной cte'шкой: https://wiki.postgresql.org/wiki/Loose_indexscan
Нативно pg пока не умеет loose indexscan. Поэтому distinct читает все элементы дерева вместо поиска следующего большего элемента.

Зачем здесь query execute? Запрос же статичен.

RETURN QUERY SELECT "id", "name" FROM "mytable" WHERE date BETWEEN t1 AND t2;

Впрочем, планировать 1,7с тут в общем-то нечего, так что это спички.

Вообще, вызов хранимки материализуется. Рабочая гипотеза - на материализации время и тратите. Что дальше происходит с данными? В explain что-нибудь полезное видно? (давненько я хранимки не разбирал, не помню, что туда попадает)