Melkij

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

Кто-то забывает делать ограничения в схеме БД. Кто-то может вовсе не знать, что 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] '

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

У www-data нет x прав на директорию /home/username/

... 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 будет возвращать одно и то же значение.
А правильно это для вашей задачи или нужно использовать другую из функций датывремени - это только к вам вопрос.

Нет, не должен. Значение NULL не противоречит такому check constraint. На самом деле даже в исходниках самого postgresql есть замечания, что такое поведение несколько неожиданно, но таков стандарт SQL.

То что в прикладной вашей задаче будет давать лучше результат.

Когда-то давно, когда в десктопах были преимущество одноядерные CPU, маркетинг любил называть частоты. Потом полюбил козырять числом ядер. Потом ещё чем-нибудь. Одна характеристика чтобы доказать собственное превосходство над конкурентом (и что не менее важно - над предыдущим поколением собственной же продукции) - это же так здорово! Только нихрена это так просто не работает.

Вот уже которое десятилетие единственный корректный ответ в выборе CPU - сравнить в конкретных условиях. Задача со звёздочкой: сравнить корректно.

В частности, вы не указали, одной ли микроархитектуры два сравниваемых CPU. А этот маленький нюанс моментально лишает всякого смысла декларируемую частоту работы. Двухкратная разница производительности на одной частоте? Почему нет, история знает такие примеры. Потом кэши, организация памяти, а из недавнего - состояние защит от атак на спекулятивное выполнение. Ежели всё это идентично и из различий только число ядер и частота - то опять же упрёмся в необходимые задачи. Однопоточному приложению будет безразлично, есть ли ещё 7 ядер или только второе.

array_agg(attr.name) filter(where ...)

Напрямую запросом, без лишнего execute

CREATE OR REPLACE FUNCTION example(arg int)
RETURNS int4
LANGUAGE plpgsql
AS $$
declare
   out int;
   BEGIN
   --function body
   SELECT field * arg into out FROM randomtable;
   return out;
   END
   $$;
select example(1);

Или, если действительно нужно генерировать динамический SQL, то передать параметром в using:

CREATE OR REPLACE FUNCTION example(arg int)
RETURNS int4
LANGUAGE plpgsql
AS $$
declare
   out int;
   somequery text;
   BEGIN
   --function body
   somequery := $q1$ SELECT field * $1 FROM randomtable $q1$;
   EXECUTE somequery into out using arg;
   return out;
   END
   $$;