А разве он собирается учиться? ;) Если это Вам мешает — поищите в -hackers, не предлагал ли кто уже такого и т.п.
Ну и patches welcome.

Да.

👍

А чем при работе с timestamptz объясняется тот момент, что при корректно настроенной на клиенте time zone, полностью совпадающей с time zone клиента, время в столбце с типом timestamptz не является реальным временем?

Я не понял вопроса. Что Вы имеете в виду?

Сейчас покажу. У меня на домашнем ноуте под виндой нет psql, поэтому не пинайте за скриншоты

При переносе кода логирования из Oracle в Postgres встал вопрос, как реализовать автономные транзакции? Т.е., чтобы вставка в таблицу (да и не только она) шла в отдельной сессии асинхронно. Как это сейчас делают? Читал, что dblink к себе - медленно, и вроде есть решения через модули pg_variables, pg_background. Надеюсь посоветуете правильный вариант (а если с примером, то вообще отлично).

Клиентский часовой пояс — Новосибирск. Серверный — аналогично. Корректное значение sent_at — 8 с копейками часов утра

При этом без явного приведения к тому же самому Нск часовому поясу или без cast'а в timestamp данные возвращаются некорретные

Вы можете текстом показать?

Результат выполнения запросов нет, к сожалению, у меня нет на данной машине psql, только IDE

И что, оттуда не копируется, что ли? ;)
Всё-таки скопируйте, и запрос тоже.

Кстати:

> Клиентский часовой пояс — Новосибирск. Серверный — аналогично.

Серверного часового пояса в PostrgreSQL не существует. Нет такой вещи в принципе, понимаете?
Т.е. на картинках Вы два раза показали одно и тоже — текущее значение time zone в сессии. И ничего другого, влияющего на данную сессию в отношении временных зон, в PostgreSQL просто нет.

Уберите каст к timestamptz, сделайте timestamp at time zone ...

show timezone 

Возвращает

Asia/Novosibirsk

select 
  sent_at as sent_at_tz,
  sent_at::timestamptz at time zone 'Asia/Novosibirsk' as sent_at__with_tz_given,
  sent_at::timestamp as sent_at_no_tz
from sap.o2c_data_request
order by sent_at desc
limit 1
offset 2

Возвращает

02.07.2021 7:09:53  02.07.2021 8:09:53  02.07.2021 8:09:53

Про show и запрос к pg_settings — да, чего-то я уже под конец дня не соображаю. В любом случае, в том же postrgesql.conf
timezone = 'localtime'
Что в нашем случае также является

Asia/Novosibirsk

Оно есть, это второй столбец как раз. Данные без явного указания часового пояса и с ним разные

Да, увидел

Возвращает
02.07.2021 7:09:53  02.07.2021 8:09:53  02.07.2021 8:09:53

Подождите, тут что-то не так в самом формате результата!

Само поле sent_at какого типа, timestamptz? Если да, то, "поздравляю" — это GUI-клиент Вам просто врёт (надо было ставить линукс psql ;) ) — ищите, как его можно "привести в чувство".
А если sent_at типа timestamp, то зачем sent_at::timestamp as sent_at_no_tz?!

> в том же postrgesql.conf
> timezone = 'localtime'

И вот эта штука — это не мистическая "серверная time zone", это time zone по умолчанию для подключающихся сессий (она может быть "перебита" на нескольких уровнях — базы, пользователя, в стартовом пакете подключения, ну SET timezone, наконец). ;)

Вот так, к примеру, это должно выглядеть:

SELECT now() AS sent_at_tz,
       now()::timestamptz AT time zone 'Asia/Novosibirsk' AS sent_at__with_tz_given,
       now()::timestamp AS sent_at_no_tz;

          sent_at_tz           |   sent_at__with_tz_given   |       sent_at_no_tz        
-------------------------------+----------------------------+----------------------------
 2021-07-02 18:48:43.506828+03 | 2021-07-02 22:48:43.506828 | 2021-07-02 18:48:43.506828

Обратите внимание на формат каждого поля — все timestamptz обязаны включать time zone при выводе, если её нет — что-то портит этот самый вывод.