Melkij

Берёте pgbackrest.
Ну или walg или barman какие.

Руками свой собственный конструктор собирать дело малополезное и, что важнее, для бекапов просто опасное.

архивные логи ДО-момента backup'а уже не нужны

до позиции LSN на момент запуска basebackup, самого старого из тех, который по вашей политике резервного копирования нужно хранить.

select (select j->>'name' from jsonb_array_elements(jsonb_field) as j where j->>'custom_twine' = 'custom_38') from tablename

Все unquoted identifiers принудительно приводятся парсером в нижний регистр.
quoted identifiers - используются как есть.
https://www.postgresql.org/docs/current/sql-syntax...

при наличии уникального ограничения по phone

insert into desc (phone, name, nickname)
select phone, name, nickname from src
on conflict (phone) do update name = excluded.name

create temp table import_data (...);
copy import_data from '/path/to/file' (format csv, ...);
insert into tablename (...) select .. from import_data where not exists (select from tablename where tablename.phone = import_data.phone) on conflict do nothing;

alter user .. set idle_in_transaction_session_timeout = ...

max_client_conn в конфиге баунсера - это максимальное число возможных подключений от клиентов к самому баунсеру.
Если у вас max_client_conn стоит, например, 100, а каждый из 20 бекендов попробует открыть по 10 соединений с баунсером - то первая сотня подключений будет успешна, остальные получат ошибку "no more connections allowed (max_client_conn)"
max_client_conn ставится в 10000 и про него надолго забываем. Штука фактически бесплатная, libevent хорошо умеет с таким работать. Но требуется выставить корректный open file limit. Каждый коннект - это файловый дескриптор, если не скорректировать настройки ОС - то будет неприятный сюрприз.

Далее, max_connections базы оставить как есть. Максимум в 100 процессов базы на всего 8 ядер - это и так довольно-таки много, но и урезать смысла нет.
max_user_connections не трогать если нет причин для этого.

pool size 20 на всего лишь 8 ядер CPU может быть чрезмерно. Но далее нужно смотреть уже мониторинг. Сколько реальных процессов базы в работе, очередь ожиданий на баунсере, хватает ли баунсеру процессорного времени (тут скользкий момент, баунсер строго однопоточный и может упираться в производительность одного ядра CPU)

https://github.com/postgres/postgres/blob/REL_15_S...

We allocate one map byte to each page, allowing us to record free space
at a granularity of 1/256th of a page. Another way to say it is that
the stored value is the free space divided by BLCKSZ/256 (rounding down).

один байт FSM отражает страницу данных.

Такой текст ошибки используется только в одном месте и суть его заключается в том, что в pg_collation нет такой строки.
Что через https://www.postgresql.org/docs/current/collation.html приводит к вопросу: существует ли локаль en_US.utf8 у вас в системе, чтобы её использовать?

Если нет - создайте локаль. Затем select pg_import_system_collations('public'); должно быть достаточно

если кратко: https://github.com/postgres/postgres/blob/REL_15_S...

только требуемые строки, в select for update (и родственниках) это видно отдельным LockRows плана выполнения