Postgres выдаёт unknown для типа char - в чём ошибка?

ERROR: function testfunc3(
1: select testboris3(

Кому верить? Пожалуй, никому: вы, вероятно, поменяли текст цитаты в вопросе.

сделайте самодостаточный тест. Вот такой create function, вот так вызывается и вот такая ошибка. Дополнить листингом \df имя_функции чтобы проверить на возможные остатки от прошлых экспериментов. Может существовать несколько одноимённых функций с разными наборами аргументов (в этом случае, правда, текст ошибки будет более явно намекать на невозможность выбрать конкретную функцию)

Почему не создается логическая репликация на Windows 10 и падает воркер?

025-11-18 14:39:19.442 MSK [12692] СООБЩЕНИЕ: процесс синхронизации таблицы при логической репликации для подписки "im_sub", таблицы "link_accessories" запущен
2025-11-18 14:39:19.442 MSK [12692] ОТЛАДКА: connecting to publisher using connection string "dbname=op_market_integration host=localhost port=5432 user=postgres password=postgres"
2025-11-18 14:39:37.447 MSK [12692] ОШИБКА: ошибка при чтении результата команды передачи:

А говорите нет ошибки помимо того что воркер завершился.
error reading result of streaming command если говорить обычным языком. Забавно что PQerrorMessage не смог добавить деталей
Что в логах публикации в это время?

Специалисты по управлению качеством в IT-компаниях есть?

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

VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

хммм, сходу не помню, надо в исходниках проверить...
https://github.com/postgres/postgres/blob/REL_17_6...
вот у нас all visible биты в visibility map пишутся, во время стадии PROGRESS_VACUUM_PHASE_VACUUM_HEAP по мере прохождения по heap_blks_vacuumed обновляем страницы и вместе с этим по каждой странице проверяем, не надо ли поставить visibility map биты

VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

bsd9, тут же, на этом же этапе перед чтением блока консультируемся у visibility map, вдруг блок можно пропустить и если это возможно.

VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

да, нужно будет прервать.
vacuum штука цикличная:
- читаем табличку последовательно от 0 блока
- hot pruning и чего-то ещё меняется и записывается сразу по мере чтения
- при этом накапливаем в массиве CTID строк, которые хотим вычистить (heap_blks_scanned)
- если на следующем блоке можем превысить допустимый размер нашего массива CTID - то запускаем vacuuming indexes, в котором читаем все индексы и удаляем из них CTID из нашего массива
- вычищаем из куска таблицы, которую за эту итерацию прошли, все эти CTID
- heap_blks_vacuumed доходит до heap_blks_scanned и продолжаем читать с того места где прервались на vacuuming indexes.

соответственно, прервать вакуум можно в любой момент, но обидно если это происходит перед vacuuming heap - тяжёлую часть по большей части выполнили, а сохраниться не успели. При следующем запуске vacuum будем жевать те же самые CTID ещё раз.
С другой стороны, если в таблице появилось дохлых CTID на 10 проходов через vacuuming indexes и мы уже сделали index_vacuum_count = 5, то вот эти сделанные index_vacuum_count уже сохранены. Если тут прибить вакуум, то следующий вакуум уже не увидит множество мёртвых строк в начале таблицы и быстро дойдёт до того места, откуда начиналась прерванная 6 итерация.

VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

А что вы в таких ситуация предпринимаете? Или остается только ждать?

начальный реиндекс если есть показания к нему
Дальше запустить вакуум и не мешать ему работать. Поглядывать за wraparound. Если грозит - тогда index_cleanup = off чтобы отодвинуть горизонт и затем дать вакууму работать дальше над индексами.
Может быть смысл в pg_repack, если обстоятельства позволяют.

Почему увеличилась генерация WAL-сегментов?

Есть такая штука как full page image (FPI) - при первом изменении страницы после чекпойнта записывается в WAL копия всей страницы, а не только изменение этой страницы. (это защита для crash recovery на тот случай, если IO записало страницу только частично, страница у нас 8кб типично, страница памяти ОС чаще 4кб, а у диска адресация может быть и 512 байт: поэтому нужно предполагать, что есть ли мы попросили записать 8кб и где-то тут всё умерло, то на дисках может быть уже записано, например, 4кб нового содержимого страницы, а других 4кб остались старые - в итоге фигня)

Вместе с накоплением bloat получается что мы регулярно трогаем бОльшее число разных блоков, что и вызывает больше записи FPI.
https://wiki.postgresql.org/wiki/Full_page_writes

Из менее очевидного и не помню чтобы задокументированного (помимо исходников), часть работы автовакуума подхватит выполнение других запросов. Так называемые micro vacuum и index hint bits, когда даже select может чего-нибудь писать в WAL. Небольшие оптимизации вида "ну это не моя работа, я выполняю запрос, но блок данных вот он в руке, всю работу по проверке видимости транзакций всё равно уже сделал, подпишу для потомков примечания чтобы они не тратили время на то же самое"

Ситуация вокруг hot_standby_feedback или max_standby_streaming_delay (max_standby_archive_delay полностью аналогично, но применяется на restore_command) в postgresql такая:
Реплика получает поток WAL, сделанных на мастере и обнаруживает, что на мастере физически из датафайла удалены данные (обычно автовакуумом), которые ещё может хотеть прочитать запрос, запущенный на этой реплике. Пропустить это изменение и накатывать репликацию дальше нельзя. Дальнейшшие изменения запросто могут быть в этом же самом датафайле, уже полагающиеся что это изменение было применено. Остаётся не так уж много вариантов что может делать реплика:
• или приостанавливать репликацию и подождать пока доработает запрос
• или отменять запрос и продолжать применять репликацию
postgresql сначала делает паузу репликации, затем по прошествии времени max_standby_streaming_delay отменяет мешающие запросы с разными вариантами terminating connection due to conflict with recovery. При этом, max_standby_streaming_delay считается от начала конфликта репликации и по таймауту снимает совсем всех кто мешает, даже если этот конкретный запрос запустился полсекунды назад.

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

Для аналитической реплики выбирается комфортный max_standby_streaming_delay. Полчаса, час, 10 часов - индивидуально по потребностям проекта. Баланс между "дать запросам поработать" и "реплика может отставать на такое время и это не авария, а полностью штатное поведение, о котором мы с вами ранее договорились"

Почему увеличилась генерация WAL-сегментов?

hot_standby_feedback бизнес потребовать не мог. Это не бизнесовая задача. Выстрел себе в ногу в попытке починить сломавшийся или нестабильно работающий бизнес-процесс - да. Но бизнесовая проблема 100% в другом и не формулируется как "включить hot_standby_feedback".

За счет того что автовакууму обрабатывать больше мертвых версий строк или не только?

не только, но первопричина вернётся к этому.
Повезёт если бонусом не ляжет вообще всё из-за замедления ответов СУБД. Некоторые проекты красиво складываются минут за 20.

Postgres Docker: Странные временные файлы в папке overlay2?

это НЕ файлы postgresql. Не то место, не то именование.
может быть malware работающий через взломанный postgres.

Как запустить mysql после ошибки?

не, тут гораздо интереснее чуть выше Operating system error number 11 in a file operation.
то есть ошибка вовсе не самого mysql, а ОС не даёт работать.

Какое отставание MySQL Slave от MySQL master считать проблемным?

Seconds_Behind_Source но с учётом прочтения описания документации по этому полю. Там не без некоторых нюансов

Как понять почему размер БД вырос на 30%?

3. Да были ошибки в логах о недоступности для записи таблиц.

можно пару цитат?

То есть основная гипотеза, vacuum full писал что-то большое, но не смог удалить либо старые либо новые датафайлы.
База при этом не уходила ли вообще в crash recovery по какой-то причине? Там есть варианты при которых остаются осиротевшие датафайлы https://www.cybertec-postgresql.com/en/orphaned-fi...

Как понять почему размер БД вырос на 30%?

- место занимает именно PGDATA/base/ ? PGDATA/pg_wal нормального размера?
- "Если сделать бэкап и развернуть на другом сервере" - какой именно бекап имеется в виду?
- ошибки в логах базы при снапшоте?
- как именно снапшот делался? (LXC на btrfs/zfs/etc тоже можно назвать виртуалкой, а вот грабли будут свои)

PS: vacuum full на 1,4тб базе это довольно неожиданная идея

В чем может быть причина сброса значения sequence в БД?

если бы типичный в такой ситуации `select setval` ещё бы считался ddl командой =) не попадёт в лог, проверил только что

Как обнаружить все битые таблицы?

Я пару файлов уже скопировал с прода и они заработали.

И тем самым сломали MVCC логику.
А ещё могли не заметить существование base/121622383/622439194.1 и так далее сегментов

Восстановите базу заново но теперь корректно. Нафига вам на тестовой базе приключения

Как заставить нормально работать относительно древнюю видеокарту в слоте PCIe x1?

проблема скорее софтовая. Когда там nvidia выбросила поддержку 8ххх из драйвера? Существовала ли в истории версия драйвера, которая поддерживает и старую и новую из ваших видеокарт?
Два одновременно активных разных версии драйвера ожидаемо к приключениям.
https://forums.developer.nvidia.com/t/setting-up-t...
попробуйте вот такое для эксперимента
https://forums.developer.nvidia.com/t/intalling-tw...

С чего начать изучение инженерной части БД?

лучше привыкать читать технические тексты на английском. Не так сложно, как кажется со стороны.

Linux udev перепутал имена сетевых карт?

посмотрите что dmesg про них писал. Сюда влезли ручки всякого systemd и сломали ранее исправно работавшее именование интерфейсов через udev при конфликтующих именах, когда надо поменять местами два имени между собой. Помогает использование имён не ethX, а, например, NAME="ethbond0" или NAME="ethlan"

Почему для триггера AFTER INSERT FOR EACH ROW ошибка: отношение "new" не существует?

NEW и OLD в триггерах - это предварительно объявленные переменные типа record.
select from не предполагает использование переменной в from и пытается искать таблицу/view/etc с таким именем.