Melkij

pg_repack - это community extension, форк более раннего pg_reorg. И не отрицая вклад участников pgpro в разработку postgresql в целом - я не вижу их среди контрибьютеров pg_repack.

Мы активно используем обе. Основные моменты касательно pg_repack vs pgcompacttable в общем-то именно я и изложил в README компактора. Если говорить на русском:
- pg_repack делает копию таблицы, т.е. требуется двукратный запас диска. Компактор работает в рамках одной таблицы и требует место только под копию наиболее толстого индекса и то, толстые индексы обрабатываются самыми последними. Т.е. расчёт на работу когда места уже мало.
- компактор намеренно выполняется медленно чтобы не задевать работающий проект
- компактор не может обрабатывать toast таблицы. Репак - может.
- pg_repack характеризуется очень заметными пиками io и wal. Вся таблица едет одной транзакцией и это никак не регулируется. Поэтому может аффектить прод на неважных дисках и в том числе оторвать реплики при недостатке сетевой полосы.
- pg_repack умеет перемещать между tablespace и может делать команду cluster

(или лучше подстроить автовакум)?

Конечно необходимо настроить автовакуум и не мешать ему работать - т.е. исключить долгие транзакции. Но всё равно бывают хитрые моменты, когда репак или компактор бывают нужны.

А с кавычками выводит "ничего" т.е. ноль полей.

С какими именно?

user='40'
'user'='40'
"user"='40'

Это три абсолютно различных условия, выполняющих совершенно разные вещи.

user - зарезервированное слово по требованию стандарта. По стандарту не уверен что обозначает в контексте where, надо искать (может как часть create user и подобных только зарезервирован), а в postgresql обозначает имя текущего пользователя. Имеет тип name, что и провоцирует ошибку.
Т.е. первое условие в принципе не имеет никакого отношения к каким-либо пользовательским таблицам.

'user' - просто текстовая константа. Никто не мешает в условии сравнивать одну константу с другой, where 1=1 в некоторых query builder отсюда же.

"user" - обращение к объекту, игнорируя зарезервированные слова. То есть если у вас в таблице proxy есть поле user - то запрос должен быть записан как
select * from proxy where "user"='40'

Но общая практика - лучше не надо использовать зарезервированные слова в качестве идентификаторов.

У postgresql есть всего одна директория - data_directory (aka PGDATA). Для работы необходима консистентная копия всей директории целиком, включая содержимое по всем симлинкам.

Можете поковырять pg_filedump, но лучше достаньте бекап.

объясните, пожалуйста, смысл ролей в постгрес

Пользователь - это алиас для системы ролей.

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

Это ложь. Необходимости нет.

Поэтому для созданного нами ранее пользователя с именем sammy соответствующая роль будет по умолчанию пытаться соединиться с базой данных sammy

А это верно. Но только если имя базы для подключения не переопределено, например, переменной окружения PGDATABASE. Ну и конечно его можно просто задавать аргументом подключения.

можно ли так: несколько ролей и одна база данных?

Разумеется. Хоть дерево со множественным наследованием ролей.

Только важный момент - роли глобальны в пределах кластера. Вы не можете сделать пользователя user в базе foo с одним паролем и пользователя user в базе bar с другим паролем. А вот дать readonly на одну базу и полные права на другую - это пожалуйста.

Вы что-то делаете странное. У вас какая версия postgresql?
Если 9.1 и выше - то единственный верный способ ставить extension - это сказать create extension в нужной базе. Обычно нужны привилегии суперпользователя базы (обычно postgres на linux или pgsql на freebsd)

Ругать на локаль - ошибка настройки самой ОС, к базе отношения не имеет.

Причина ошибки хранимки полностью и достоверно указана в подробностях текста ошибки:

It could refer to either a PL/pgSQL variable or a table column.

У вас в табличке есть поле id, у хранимки аргумент id - который из них подразумевается парсер не понимает.

С insert или update по результату select (к слову, совершенно ненужному запросу) вы вляпываетесь в race condition
on conflict специально сделан для нормальной сериализации происходящего и использоваться и должен. Другие способы сериализации race condition из времён до on conflict производительность просаживают по вполне очевидным причинам.

select extract(epoch from now() - MAX(DATE_OP)) seconds_ago from tablename;

json нужно использовать если у вам надо хранить json и сохранять полностью его форматирование. Форматирование именно самого json с пробелами, табами и переносами строк - т.е. как текст, но с валидацией что здесь именно json.
если вам нужно хранить json - лучше использовать jsonb
А для описанной задачи и просто массива достаточно, bigint[] или text[]. Контактные данные для заказа уместны именно в заказе, а по jsonb и массивам возможно вполне внятно и искать в том числе

Для uuid в принципе не нужен текст, есть нативный одноимённый тип данных.

При этому line иногда плавает.

Проверьте память. Физическую на сервере. Подозрение что косячит.
И диски тоже проверьте.
Потому что есть всего одно место, где можно поймать "compressed data is corrupted" и связано оно с распаковкой сжатых данных из toast. reindex тоже говорит, что прочитано что-то совсем не то, что предполагалось.