Вроде в шляпе аудит по дефолту писался

И вот эти вот картинки открывать совсем нет желания. Будьте добры привести текст. И я вам указал на SELinux и превышение каких-то системных лимитов.

или ФС сыпется

сейчас запрошу

Нет. Миграция виртуалок только просаживает скорострельность.

я бы рад, но мы получаем те же картинки от админов заказчика...

Ууууууу...

в ответ к первым двум пунктам:
конкретно с timestamptz. Даже если сказать SET timezone='utc', timestamptz отображается в локальном времени. У pgAdmin дефолт - такой же (локальное время компьютера), но хотя бы SET timezone='utc' работает.
Установку таймзоны на уровне конфигурации клиента не нашёл, post-connect/pre-query hooks тоже, чтобы не писать этот SET timezone руками (может, недостаточно хорошо искал). Если найду что-то такое - этот минус пойдёт под нож - выставить всем пользователям utc по умолчанию, использовать timestamptz и никаких неожиданностей.

Заодно я бы  поинтересовался когда там переносы были последний раз перед проблемными моментами. Хотя бы на уровне "давно тут сидит" или "незадолго до проблем переезжала"

у них бывает до пары раз в день...

А БД большие?

зачем - вопрос хороший, они говорят что этим не управляют... сказали что запросят привязку машины к конкретному железу что бы не уезжала

пока пару десятков гб, нагрузки пока нет ибо только вводим в эксплуатацию

Ну если переехала и тут же проблемы - уже зацепка ящитаю.

оно уже почти неделю так

WITH flights(real_sequence, dep_utc) AS (
   VALUES
   (1, timestamp '2014-10-25 21:07:00'),
   (2, timestamp '2014-10-25 22:05:00'),
   (3, timestamp '2014-10-25 23:05:00')
)
SELECT *, dep_utc AT TIME ZONE 'UTC' AT TIME ZONE 'Europe/Moscow' AS dep_loc
  FROM flights
 ORDER BY dep_loc;

это сортировка по локальному времени, выглядящая корректно =)
Будь нужен фактический порядок (а не по часам вот в этом пункте) - была бы сортировка по utc. Хотя интересно, как эти переходы отрабатывают непосредственно в аэропортах. Рассчитывают, что у всех пассажиров часы переводятся автоматически?
(ушёл гуглить)

> Даже если сказать SET timezone='utc', timestamptz отображается в локальном времени.

"Весело". Вообще, это отсебятина (баг) клиента, по-хорошему.
Т.е., на самом деле, если time zone сессии — UTC, а локальная tz = 'Europe/Moscow', то, если я напишу:

SELECT date_trunc('day', now());

То увижу "2020-06-15 03:00:00", что ли?!


> Установку таймзоны на уровне конфигурации клиента не нашёл

Ну это нужно в настройки JDBC / клиента смотреть, тут не подскажу... а что, он при подключении всегда сам выполняет "set timezone" (иначе должен использоваться default, см. выше)?

Коллеги,добрый день. Возник вопрос с FTS. При конвертации строки в tsquery у английского слова обрезается окончание(видимо,движок предполагает,что это множественное число),даже если выбран русский словарь. Можно ли производить конвертацию таким образом,что над русскими словами postgres будет производить манипуляции,а над английскими - нет?

Это точно не репликация. Вот репликация: https://www.postgresql.org/docs/11/warm-standby.html#STREAMING-REPLICATION

Только вот она некорректна, самолёты на самом деле прилетали не в этом порядке. Если от этого зависит что-то важное — упс! ;(