pgsql – PostgreSQL

11 Mar 2025 12:27

Всем привет)
Вопрос такого плана, с двух инстансов постгреса в контейнерах, можно настроить репликацию логическую в один контейнер на другом сервере? Судя по доке вроде можно, решил уточнить

pgsql – PostgreSQL

11 Mar 2025 12:16

Коллеги, при обновление базы

 sudo -iu postgres /usr/pgsql-17/bin/pg_upgrade --old-datadir "/data/postgres" --new-datadir "/data/postgres-17/" --old-bindir "/usr/pgsql-14/bin/" --new-bindir "/usr/pgsql-17/bin/"

pg_restore: creating ACL "pg_catalog.FUNCTION "close_lb"("line", "box")"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 15431; 0 0 ACL FUNCTION "close_lb"("line", "box") postgres
pg_restore: error: could not execute query: ERROR:  function pg_catalog.close_lb(line, box) does not exist
Command was: GRANT ALL ON FUNCTION "pg_catalog"."close_lb"("line", "box") TO "cits_user";

pgsql – PostgreSQL

11 Mar 2025 11:22

всем привет!
подскажите плиз, пытаюсь подружить Postgres Pro Standart (15 ver) с pgBackRest 2.54.2
получаю сообщение по ошибке архивации валов на s3:

ERROR: [046]: unexpected control version = 1347421460 and catalog version = 202209071
HINT: is this version of PostgreSQL supported?

pgsql – PostgreSQL

11 Mar 2025 10:58

Всем привет, подскажите как установить pg_amqp для postgres-17 Oracle linux-9, пробовал

git clone https://github.com/omniti-labs/pg_amqp.git
cd pg_amqp
PATH=/usr/pgsql-17/bin:$PATH make install

src/pg_amqp.c:99:10: warning: 5 enumeration values not handled in switch: 'XACT_EVENT_PARALLEL_COMMIT', 'XACT_EVENT_PARALLEL_ABORT', 'XACT_EVENT_PRE_COMMIT'... [-Wswitch]
   99 |   switch(event) {
      |          ^~~~~
src/pg_amqp.c:140:21: error: parameter 'broker_id' was not declared, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
  140 | local_amqp_get_a_bs(broker_id) {
      |                     ^
src/pg_amqp.c:140:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C23 [-Wdeprecated-non-prototype]
  140 | local_amqp_get_a_bs(broker_id) {
      | ^
src/pg_amqp.c:152:19: error: parameter 'broker_id' was not declared, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
  152 | local_amqp_get_bs(broker_id) {
      |                   ^
src/pg_amqp.c:152:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C23 [-Wdeprecated-non-prototype]
  152 | local_amqp_get_bs(broker_id) {
      | ^
src/pg_amqp.c:239:23: error: parameter 'broker_id' was not declared, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
  239 | local_amqp_disconnect(broker_id) {
      |                       ^
src/pg_amqp.c:239:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C23 [-Wdeprecated-non-prototype]
  239 | local_amqp_disconnect(broker_id) {
      | ^
4 warnings and 3 errors generated.
make: *** [/usr/pgsql-17/lib/pgxs/src/makefiles/../../src/Makefile.global:1085: src/pg_amqp.bc] Error 1

pgsql – PostgreSQL

11 Mar 2025 10:42

Странно вот это выражение звучит. Будто про INTERVAL забыли.

pgsql – PostgreSQL

11 Mar 2025 10:39

Всем спасибо за участие и помощь!

pgsql – PostgreSQL

11 Mar 2025 10:30

Я не понимаю, что такое "рабочее" время.

pgsql – PostgreSQL

11 Mar 2025 10:29

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

pgsql – PostgreSQL

11 Mar 2025 10:23

Зачем, для решения какой задачи? ;)
Это время и так изоморфно тому времени, которое было у пользователя (точнее, это буквально одно и то же).

pgsql – PostgreSQL

11 Mar 2025 10:17

Почему? Это offset, который был у пользователя, от которого приехало значение временной метки (и оно никак не связано с вами, и никак не связано с меткой в формате UTC/GMT с нулевым смещением, т.е. про него можно "забыть").

Пример:
Сейчас я в Нью-Йорке, у меня локальное время 05:17 утра (и оно в формате GMT-04:00, таков уж там часовой пояс). Я пришел к вам в сервис и он записал моё время. Получилось:
created_on = 09:17, offset = GMT-04:00

Однако, если вы created_on приведете к timestamptz корректно и выведете у себя, вы получите 12:17, т.е. московское время (GMT+03:00).

pgsql – PostgreSQL

11 Mar 2025 10:13

Я ожидаю, что к столбцу created_on прибавиться время как в offset. Если посмотреть на стручку где оффсет +7, то там тоже прибавляет +3 часа

pgsql – PostgreSQL

11 Mar 2025 10:01

Ну смотрите, мы с помощью AT TIME ZONE 'UTC' показываем, что в этом столбце с типом timestamp хранится временная метка в формате UTC/GMT. После оного приведения этот столбец (ну, текущее выражение, точнее) становится типа timestamptz и далее он выводится на клиент в локальном формате времени (в вашем случае по Москве, т.е. в UTC/GMT+03) — стандартное поведение для типа timestamptz.

Иначе говоря, то, что везде "прибавляется 3 часа" — так и должно быть на вашем клиенте, ведь теперь время отображается не как UTC, а как UTC+3 (в локальном для вас формате).

pgsql – PostgreSQL

11 Mar 2025 09:57

не знал. =) должно подойти.
я краем мозга вспомнил линуксовый tr, когда возился, но тут же и забыл.

pgsql – PostgreSQL

11 Mar 2025 09:57

И как насчет:

SELECT translate(ts, '+-', '-+')

pgsql – PostgreSQL

11 Mar 2025 09:52

и это поправить у меня получилось только через уродливый CASE. пример:

postgres=# WITH tz AS (SELECT unnest(ARRAY['GMT-03:00', 'GMT+08:00']) AS offset) SELECT CASE WHEN "offset" ~ '^GMT\+' THEN replace(tz."offset", '+', '-') WHEN "offset" ~ '^GMT\-' THEN replace(tz."offset", '-', '+') END FROM tz;
  replace
-----------
 GMT+03:00
 GMT-08:00
(2 rows)

Time: 0,986 ms

pgsql – PostgreSQL

11 Mar 2025 12:24

я б попробовал убрать права на эту ф-цию до апгрейда.
вон тут у народа что-то похожее
https://postgrespro.com/list/thread-id/2634400

pgsql – PostgreSQL

11 Mar 2025 11:23

Написать патч и скомпилировать.

pgsql – PostgreSQL

11 Mar 2025 11:00

Знаете, ставить расширение 6-летней свежести на PostgreSQL 17 наверное, и правда плохая идея (и вообще ставить то, что не поддерживается авторами хотя бы для какой-то версии).

Рекомендация: забыть про это расширение (несмотря на то, что сторонние разработчики предлагали фикс подобной проблемы).

pgsql – PostgreSQL

11 Mar 2025 10:43

Не бывает смещения часового пояса больше чем часов в сутках, interval тут чрезмерен (16 байт против 8 байт, в т.ч.).

upd.: Хотя, я проворонил отрицательные смещения, в этом смысле interval подойдет лучше, да (иначе придется нормировать по минимальному часовому поясу UTC-12:00, что уже в тип time не влезает в худшем случае; ну, или отдельно хранить знак в виде bool).

pgsql – PostgreSQL

11 Mar 2025 10:40

Есть INTERVAL

pgsql – PostgreSQL

11 Mar 2025 10:38

Ок, тогда в целом подойдет костыль выше, да.

Правда я рекомендовал бы вам заменить тип столбца offset на, напр., time (подразумевая, что это смещение от GMT/UTC), раз уж нужно знать какой у пользователя часовой пояс. Потом бы просто можно было б делать аля:

SELECT created_on + offset;

pgsql – PostgreSQL

11 Mar 2025 10:30

в целом этот скрипт работает c.created_on::timestamp AT TIME ZONE 'GMT' AT TIME zone translate (tz.offset, '+-','-+')

pgsql – PostgreSQL

11 Mar 2025 10:28

set timezone TO 'GMT';

pgsql – PostgreSQL

11 Mar 2025 10:22

Мне московское время не нужно, нужно время места где был пользователь

pgsql – PostgreSQL

11 Mar 2025 10:14

прибавляет ваш часовой пояс ?

pgsql – PostgreSQL

11 Mar 2025 10:06

Что вас смущает? Вместо немого скриншота всегда рекомендую указывать ожидаемый результат и почему вы его ожидаете (а скриншот зачтем за "актуальный").

pgsql – PostgreSQL

11 Mar 2025 09:58

У вас created_on это столбец timestamp или timestamptz?

pgsql – PostgreSQL

11 Mar 2025 09:57

Он всем прибавляет 3 часа....

pgsql – PostgreSQL

11 Mar 2025 09:54

Коллега уверяет, что в столбце created_on уже приведенное время к UTC/GMT, т.е. столбец offset вообще не требуется для работы с этим временем как таковым.

pgsql – PostgreSQL

11 Mar 2025 09:51

Хм, так тогда достаточно сделать:

created_on AT TIME ZONE 'UTC'