Melkij

Вы что-то делаете странное. У вас какая версия 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 производительность просаживают по вполне очевидным причинам.

Варнинг в мануале для чего дан? php.net/manual/en/function.sprintf.php

Warning Attempting to use a combination of the string and width specifiers with character sets that require more than one byte per character may result in unexpected results

Потому что указание длины строки в printf работает в байтах, а не символах.

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

where datefield >= '2017-01-01' and datefield < '2018-01-01'

Или если несподручно считать следующую дату:

where datefield >= '2017-01-01' and datefield < '2017-01-01' + interval 1 year

Только не надо делать якобы простое where year(datefield) = 2017, который будет перебирать всю таблицу потому что в принципе не может использовать индексы.

Контроллер памяти в процессоре и ограничивает. Datasheet на 19-20 страницах описывает поддерживаемые модули - модулей по 32гб каждый там нет, максимум процессор умеет 4 DIMM по 16гб каждый = 64гб.
А на указанной материнской плате просто физически некуда вставлять столько памяти - слота всего два вместо 4, на которые рассчитан максимальный поддерживаемый объём.

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

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

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

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

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

поэтому проще будет найти файлы и все попереносить.

И так делать нельзя и ничего кроме бесполезного файлика с бинарным мусором вы в резуультате не получите.
Прочитать данные из raw файлика, а уж тем более подсунуть его в другую базу - очень сильно замучается даже опытный DBA, способный читать и понимать исходный код postgresql (это кстати минимальное требование к тому чтобы что-то достать из сырого файлика таблицы).

Потому что директория базы PostgreSQL - это один неделимый объект (плюс tablespace, которые отделять тоже нельзя от данных кластера). Для чтения данных из файлов таблицы (их много может быть) нужен системный каталог, нужен toast (если был создан), нужны clog и xlog чтобы понять, а что мы собственно в этом файлике видеть должны, а что просто ещё не вычистил вакуум.

Если вам нужны данные из конкретной таблички - сделайте логический снимок таблички уже упомянутым pg_dump.

Так сравниваются массивы - поэлементно по количеству элементов в меньшем из массивов.
Если элементы идентичны - сравниваем длины массивов. Поэтому массивы в таком виде вам подходят слабо.

Может лучше ваш список смежности вовсе заменить на штатное материализованное представление ltree?
Ну или во всяком случае на него можно заменить ваши массивы.