Melkij

При отсутствии явных функций форматирования даты в запросе стиль вывода timestamp задаётся настройкой datestyle. Это на выбор несколько предустановленных форматов. Для таймзоны форматирование вида здесь. Стиль USE_XSD_DATES используется в xml и json, но через datestyle его использовать невозможно, а потому минутная часть в выводе будет присутствовать только отличная от нуля.

В целом, форматирование датывремени - это не задача запроса к базе, это задача вывода данных в конечном приложении.

Начну с конца - для индексов это критично разные вещи. Планировщик даже пытаться анализировать не станет, эквивалентные это условия или нет. Если у вас есть индекс по my_column -> 'a', а в запросе вы написали "my_column"['b'] - то этот индекс использоваться не будет.

Касательно самих двух операторов:
-> ровесник jsonb как такового
jsonb[element] - jsonb subscripting на языке документации - штука недавняя, лишь только прошлогодняя из pg14. Пока что нужно иметь в виду если вам может потребоваться более старая версия базы.
По поведению отличий вроде не должно быть никаких. Оба варианта возвращают jsonb, поэтому IRL куда чаще используется ->> возвращающий текст.
На уровне реализации оба приходят к одному и тому же getKeyJsonValueFromContainer. Вы скорее упрётесь в производительность разбора формата самого jsonb, чем заметите какую-то разницу в производительности родного оператора от type subscripting.

• 3 независимых экземпляра postgresql на разных портах через потоковую репликацию. Просто, стабильно, надёжно
  
• какая-то из форм логических репликаций. Приключения по сопровождению за свой счёт. Начать с pub/sub как штатный механизм
  

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

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

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

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

... DO UPDATE SET payment_date = info.payment_date + interval '23 hours';

Данные конфликтующей строки доступны

The SET and WHERE clauses in ON CONFLICT DO UPDATE have access to the existing row using the table's name (or an alias), and to rows proposed for insertion using the special excluded table.

имени таблицы (или алиаса указанного в запросе) - та версия строки что есть
псевдоним excluded - те значения что этот insert предполагал записать

Документация отвечает однозначно

Current date and time (start of current transaction);

current_timestamp - это всегда время начала транзакции. Сколько бы транзакция ни заняла времени, до её окончания current_timestamp будет возвращать одно и то же значение.
А правильно это для вашей задачи или нужно использовать другую из функций датывремени - это только к вам вопрос.