Melkij

Зависит от:
0) какой промежуток времени вам допустимо потерять при восстановлении
1) сколько места вы можете выделить для хранения бекапов
2) какой запас времени вы хотите сохранять для возможности восстановить данные когда-то из более далёкого прошлого

Может, на мыло тоже отправлять на всякий случай?

Как через почту пропихнуть даже мелкие бекапы в десяток гигабайт?
Или вы про совсем крошечные базы спрашиваете?

Шифровать или нет - зависит от требований к безопасности и оценке риска в случае disaster recovery не восстановить ключ шифрования.

Для хорошего point in time recovery - pg_basebackup + pg_receivexlog (archive_command только если уверены, что можете её сделать нормально). Или что-то, работающее поверх них.
Отдельный случай pitr с хранением в амазоне - см. вполне внятный wal-e
Если pitr не обязателен, то pg_dump делать. Да, лучше архивировать, сжимаются дампы весьма неплохо.

Например, политика бекапа из практики: ежедневный pg_dumpall, хранятся за 1 число каждого месяца на протяжении года плюс 8 дней предыдущих ежедневных.

Что-то ещё - регулярно пробовать восстановить и запустить базу из бекапа.

Помимо log_statement = 'all' можно выставить настройку log_min_duration_statement в 0 - она тоже может логировать все запросы.

Если запросов через базу проходит много не только от необходимой программы, то и log_statement и log_min_duration_statement возможно выставить только для пользователя, от имени котрого программа выполняет запросы. Например,

alter user melkij set log_min_duration_statement = 0;

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

бэкап всех БД - 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 будет жить по своим особым правилам, как и сторонние триггерные решения.