Да я-то как бы с этой машины не работаю, в целом, с рабочего ПК все отлично пашет.
Поле там типа timestamptz, да

А что в формате результата не так? Паттерн его вывода никак же на сами данные не влияет, а именно в таком паттерне мы отдаем информацию заказчикам.

Про текущее значение для time zone я уже показывал — там значение времени Нск

> Поле там типа timestamptz, да

Точно? Потому что если с форматом всё нормально, то при типе поля timestamp подобный результат ещё может быть.

> А что в формате результата не так?

Я объяснил и показал, что не так. Этому клиенту просто нельзя верить — что тут дальше разбираться-то? ;(

Я вам еще более забавный артефакт могу показать

SELECT now() AS now,
      now()::text as now_text

02.07.2021 21:53:09  2021-07-02 22:53:09.227937+07

Но, видимо, да, дело в клиенте. Другое дело, что непонятно, почему вообще так может происходить

Это явный "косяк" клиента, больше ничего — выкиньте его в мусорное ведро найдите, как там это настраивается. ;)

Он "умничает" и что-то куда-то преобразует, видимо.
Например, читает значение типа timestamptz в бинарном формате, и преобразует в "свою" time zone (которую он берёт неведомо откуда). Да и другие варианты можно придумать... но какая разница? ;)

Зря вы так на Aqua Data Studio — ничего более удобного для выгрузок большого объема данных напрямую в Excel или сортировки этих уже полученных данных без повторного выполнения запроса внутри самой IDE (как это делают условные DataGrip, Toad, да тот же pgAdmin) и без необходимости листать эти результаты батчами по 100/500/1000/другое_очень_маленькое_количество строк

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

А результат этого асинхронного вас интересует? Я вот обнаружил что мои девелоперы под асинхронно подразумевают "в отдельной транзакции"

Ну это уж кому что нравится, но проблема-то есть...

Постоянный dblink в рамках сессии вполне быстр, если вы можете себе позволить в два раза больше сессий

Асинхронность не обязательна, главное автономность конечно, согласен.

Покопался в issues у производителя IDE, нашел там ссылочку на postgresql.org, где такое поведение объясняется поведением java.sql.Time

https://www.postgresql.org/message-id/alpine.BSO.2.00.1005190257480.27053@leary.csoft.net

Так что это, видимо, та самая знаменитая небагафича

А как такое реализовать? Мне казалось, что dblink поднимается каждый раз на запрос? И для этого и использовал кто-то из конференции PGconf разширение pg_variables.

dblink_connect/dblink_exec https://www.postgresql.org/docs/14/dblink.html

Тут  два преобразования времени происходит: в postgresql и в java и  в обоих используется сввоя база таймзон. Так что смотрите ещё и на клиентском месте, корректно ли у jre/jdk временная зона определяется, не устарела ли

Спасибо, изучу

У нас получилось порядка 20% penalty по сравнению с транзакциями в той же сессии.

Прилично...

А может Вам postgres_fdw понравиться?