Melkij

А смысл говорить про права если вы даже не подключились к базе?

Хотите просто и не разбираться с правами - от postgres и снимайте дамп. sudo -u postgres pg_dump ...

> pg_restore_log.txt

это stdout. А есть ещё stderr, куда всё интересное про ошибки и пишется. А так же verbose туда пишется, который вы запросили.
cmd 2> stderr.log

Ошибку пожалуй попробую даже угадать:
- owner не superuser
- у вас postgresql < 11.0
- ошибка прилетает на plpgsql extension который в новой базе уже есть, но его пытается воспроизвести pg_restore

Момент первый: какой synchronous_standby_names?
Момент второй:

репликация через настройку synchronous_commit = on

https://www.postgresql.org/docs/current/runtime-co...

When set to on, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to disk.

When set to remote_apply, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s).

Разницу чувствуете?

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

Очень необычный workload. Ни разу такого не встречал.
Мне любопытно, что вы такое делаете, что вам неважна латентность записи, у вас тяжёлая пишущая нагрузка (не путать с объёмом пишущей нагрузки - репликам это всё писать придётся так же, но ещё и читать), очень много крайне критичного к лагу асинхронной репликации чтения.

\dt+ показывает pg_catalog.pg_size_pretty(pg_catalog.pg_table_size(c.oid)) as "Size",
pg_total_relation_size - это pg_table_size + размер индексов таблицы.

Все они считаются здесь: https://github.com/postgres/postgres/blob/REL_11_S...
Итого вы не посчитали размер индексов на toast. Как правило он там один

слои файлов (main, fsm, vm)

Это relation forks

Стена ненужного кода и текста там где достаточно лишь переводчика.

there is no unique constraint matching given keys for referenced table "users"

Переведите.
Посмотрите на свои foreign key
Найдите что СУБД возмущается конечно имея полные на то основания

create extension ltree;

ORDER BY ID

хм.

Покажите explain (analyze,buffers) запросов. И покажите планы запросов с "ORDER BY ID + 0". И ещё

select * from pg_stats where tablename = 'table' and attname = 'column'

Я предположу что у вас вовсе не in медленный, а or ломает оценку планировщика, но в этом конкретном случае это оказывается неожиданным благом.

Зависит от схемы расположения реплик.

Каждое соединение репликации использует один из допустимых max_wal_senders хоста к которому подключается. Если вы настраиваете слоты репликации - то вдобавок вам нужно соответствующее число max_replication_slots на этом хосте.
pg_basebackup в свою очередь использует до двух коннектов max_wal_senders и до одного max_replication_slots (зависит от параметров запуска и версии)

Так если вы будете копировать все 10 реплик одновременно с помощью basebackup с одной мастер-базы - вам понадобится 20 max_wal_senders и 10 max_replication_slots. После запуска реплик будет использовано 10 max_wal_senders и от 0 до 10 max_replication_slots - смотря как настроите. Для каждой реплики отдельный слот репликации если вы хотите использовать слоты репликации.
Но это если настраивать репликацию без каскада.
Коннекты репликации считаются не по кластеру, а подключённые к конкретному инстансу. В случае каскада у вас легко может быть схема, например:
с мастера репликацию читают 3 реплики, с каждой из них репликацию получают ещё по 3 реплики - вот уже 9 реплик, а использовали только по 3 walsender на хост.

И при таком числе реплик весьма рекомендую делать каскад. И сеть на мастере поберечь и в случае переключения мастера придётся меньше баз рестартовать (primary_conninfo всё ещё меняется только рестартом всей базы, шанс у моего патча быть принятым в pg13 весьма призрачный)

Не надо использовать большой offset. Всё. В любой СУБД.
https://use-the-index-luke.com/no-offset
https://use-the-index-luke.com/sql/partial-results...

Никаких.

главное возможно ли при такой схеме гарантировать базам на кластере какие-то ресурсы (кроме диска)?

Вы даже io гарантировать так не сможете. Потому что WAL пишется строго один.

один пользователь не может выесть больше чем work_mem на бекэнд

Может. Запросто. Вы некорректно читаете документацию, там про это отдельно сказано.
И может №2 - set work_mem to '..'

Создал реплику, все реплицируется. Но у нее нет postgresql.conf

Всё у неё есть. Без config_file postgresql вовсе не запустится с ошибкой "could not access the server configuration file".
Ищите где потеряли.
show config_file;
на запущенной базе.

Сейчас версия postgis 3.0.0

https://postgis.net/2019/10/20/postgis-3.0.0/

Note that a major change in 3.0 is that the raster functionality has been broken out as a separate extension.

-- install these if you need them
CREATE EXTENSION postgis_raster;

explain (analyze,buffers) с включенным track_io_timing покажите.

Варианты:
- вы проводите весь час времени не на сортировке, а где-то ещё о чём решили не писать. Соответственно вопрос неактуален и искать надо там где обронили, а не где светло.
- у вас несоответствующие настройки автовакуума (читай дефолтные)
- время занимает filesort, а от ssd у вас по ошибке стоят read-optimised.

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

SELECT increment FROM information_schema.sequences where sequence_name = 'example' and sequence_schema = 'public';

В postgresql 10+ можно обратиться к системному каталогу так

select increment_by from pg_sequences where schemaname = 'public' and sequencename = 'example';

До 10 релиза посмотрите в
select * from public.example;
(нет под рукой чтобы уточнить имя поля)

Но если не нужны детали реализации postgresql - то information_schema.sequences вероятно будет уместнее т.к. маловероятно будет изменяться в major релизах.

Ну раз уж позвали...

очень плохо документирован

Тут полностью согласен.

давно не обновляется и не поддерживается

А вот тут смотря что подразумевать.
pgq доступен для postgresql 12 - и для этого был ряд коммитов в pgq в этом году. Аналогично в этом году адаптировали скрипты для python3 вместо бывшего ранее python2. То есть вообще-то поддерживается если трактовать как усилия направленные на восстановление работоспособности.

или вообще не стоит использовать postgresql, а использовать специализированную базу данных?

Если вам нужна транзакционная очередь в postgresql - ничего лучше pgq мне неизвестно. Самописные реализации делаются просто и дают фейерверки в работе под нагрузкой. О том смотрите доклады моих коллег, ссылку на доклад Алексея вот уже привели.
Если вам нужна очередь без привязки к транзакциям в базе - имеет смысл посмотреть специализированные брокеры. Затруднюсь что-то подсказать конкретное.