Melkij

mdadm --grow /dev/mdX -n 2

Весь раздел https://www.postgresql.org/docs/current/internals.html
за исключением разве что System Catalogs

Узел Index Scan в плане запроса - это далеко не одна функция, а целый отдельный src/backend/executor/nodeIndexscan.c
Ну и кучка поддерживающих конструкций, чтобы от этого был толк. Большая кучка конструкций. Очень.

Как функция index scan в postgresql понимает тип индекса?

А ему и не надо.
Если планировщик выбрал index scan - значит этот index access method предоставляет совместимый интерфейс. Далее index scan согласно контракту index access method дёргает методы этого конкретного AM, и уже сам AM решает, где у него что лежит и как доставать требуемые TID по заданным условиям.

и как именно Postgre понимает, какую функцию следует применять

postgresql или postgres. Базы postgre не существует.
А муками выбора о плане запроса страдает планировщик, работающий перед executor'ом. И там настоящая чёрная магия (и костыли)

Добавьте в log_line_prefix как минимум %h, затем ищите на том хосте, кто может пытаться запустить walsender. Это может быть как физическая, так и встроенная логическая репликация.
%u в log_line_prefix покажет каким логином этот процесс авторизовался, может навести на какие-то мысли о том что именно искать.

Эти две команды именно про enum:

ALTER TYPE name ADD VALUE [ IF NOT EXISTS ] new_enum_value [ { BEFORE | AFTER } neighbor_enum_value ]
ALTER TYPE name RENAME VALUE existing_enum_value TO new_enum_value

Вот удаления значения из enum нет.

Команды ADD/DROP/ALTER/RENAME ATTRIBUTE там же - это как раз про композитные типы. Уже используемые менять можно.

и деморализующий ответ от postgresql DBA

Вливаюсь в администрирование(в postgres на данном этапе)

То есть опыта системного администрирования нет?
А сколько лет опыта в разработке?
Если оба ноль - выберите себе цель более реальную.
Я не знаю ни одного DBA, у которого за плечами не было бы заметного опыта или системного администрирования или в разработке (у меня вот до сих пор больше лет опыта собирания граблей в разработке, чем опыта DBA).
И, что для вас куда хуже, не имею представлений для какой работы может понадобится DBA без существенного багажа знаний, который подразумевает эта работа. Открыл вот HH и почему-то не могу найти вообще ни одной вакансии junior DBA. Да что говорить - полный результат поиска вакансий postgresql DBA укладывается в одну страницу.

Таковы реалии DBA. Обычно будущий DBA выглядит или как опытный сисадмин, вникающий в работу SQL или как разработчик, к которому приходят коллеги с вопросами про работу СУБД.

примеры проектов, которые не оторваны от реальности.

1. доклад на конференции
   
2. тут бы я написал sql ru, но его больше нет. Попробуйте отвечать на q&a хабра или ru.so. По моим наблюдениям они бесполезны и активность тут никого не интересует, в отличии от sql ru. Но зато некоторого опыта набраться можно, попутно потренировав ключевой навык любого IT - поиск информации
   
3. посты на хабре
   
4. вменяемый bug report (в самом postgresql или широко известных штуках рядом), впоследствии исправленный
   

Что DBA может показать на гитхабе? Не знаю, postgres/postgres коммит с упоминанием своего имени, разве что.
Дамп какой-то базы? Если только с детальным описанием предметной области и задач. А читать это всё хоть кто-то будет?

Не связано с микросервисами никак. Может встретиться в любых приложениях, работающих с базой.

Кто-то забывает делать ограничения в схеме БД. Кто-то может вовсе не знать, что FK и check constraints существуют. Кто-то считает что проверки на приложении достаточно. (в этом случае бывает забавно показать примеры уже лежащих в БД данных, невозможных с точки зрения логики приложения)

Сознательный, реально обоснованный отказ от FK - штука крайне редкая

Разве дебиан удаляет старую версию из репозитория?

В список пакетов debian как правило публикует только одну доступную версию пакетов для этого релиза. (я не знаю примеров исключений этого правила, но не могу гарантировать что так всегда)
При обновлении пакета, список пакетов начинает указывать на другую версию, старая версия пакета более в списке пакетов не числится и поэтому apt не может поставить эту конкретную версию.

melkij@melkij:~$ apt-cache policy openjdk-11-jre
openjdk-11-jre:
  Установлен: (отсутствует)
  Кандидат:   11.0.16+8-1~deb10u1
  Таблица версий:
     11.0.16+8-1~deb10u1 500
        500 http://security.debian.org buster/updates/main amd64 Packages
     11.0.14+9-1~deb10u1 500
        500 http://ftp.ru.debian.org/debian buster/main amd64 Packages

Вот так смотрится какие версии доступны в загруженных репозиториях.

Если вы хотите жёстко зафиксировать определённые пакеты - вам вероятно нужен собственный репозиторий, запиненный более высоким приоритетом относительно штатных. Принимая попутно все сопутствующие риски и работу сопровождения обновлений, в первую очередь security.
Либо не фиксировать конкретную версию пакета.

Используйте более подробный log_line_prefix. В частности, нужен %h

log_line_prefix = '%m %p %u@%d from %h [vxid:%v txid:%x] [%i] '

Мы такой используем если нет значимых причин для иного.