Почитал, спасибо. Если RPO сутки, а RTO два-три часа, а дамп используется перед изменениями в одной базе, которые возможно приведут к ошибкам и необходимости откатить состояние на момент перед изменениями приемлемо его использовать?

А Вы откуда знаете, что этот дамп восстановится за два-три часа?
В том-то и суть — в этом нельзя быть уверенным в нетривиальных случаях.

> а дамп используется перед изменениями в одной базе

И вот поэтому идеальная ситуация (т.е. к этому стоит стремиться по мере возможности, в принципе)  — это когда на сервере PostgreSQL только одна production база.

Этож серверов не напасешься :)

> И вот поэтому идеальная ситуация (т.е. к этому стоит стремиться по мере возможности, в принципе)  — это когда на сервере PostgreSQL только одна production база.

каждому микросервису отдельная база в отдельном kubernetes контейнере )))

https://ru-postgres.livejournal.com/64256.html Добавил вопрос по бекапам.

Спасибо!
Ещё бы модераторы добавили ссылку на эту в описание группы — совсем бы было хорошо. ;)

Подскажите как настрокить чтобы клиент postgres определял timezone по умолчания из среды запуска как в mysql ?

А потом эти адепты микросервисов с вытаращеными глазенками безуспешно пытаются родить согласованность данных в микросервисах, ага. Уже довелось наблюдать.

Повбывав бы за микросервисы, однако.

В шапке - ссылка на официальный FAQ. В котором ни слова про бекап нет. :(

А я про описание группы (чтобы не "терялось" и т.п.)...

А, понял, отстал.

Хмм... какой клиент? Произвольная программа, использующая сервер PostgreSQL?
Такого не может быть (кто захочет — перебьёт).

В 9.1 был функционал определения timezone через - C library function localtime()

If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone. If TZ is not defined or is not any of the time zone names known to PostgreSQL, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime(). The default time zone is selected as the closest match among PostgreSQL's known time zones. (These rules are also used to choose the default value of log_timezonelog_timezone, if not specified.)

Потом убрали 🙁

Может кто знает как вернуть ?
Ключик при сборке ?

А зачем Вам это нужно?
У Вас что, временная зона сервера, на котором работает PostgreSQL, систематически меняется?
И даже если и так, клиентам-то до этого вообще какое дело?

Если клиенты в разных таймзонах они видят время в dateltime with zone в своём локальном времени по умолчанию.
А так будут видит время в тайм зоне сервера :(

> Если клиенты в разных таймзонах они видят время в dateltime with zone в своём локальном времени по умолчанию.

Значит, такие клиенты. Ещё раз, если они это явно выставляют — Вы никак это не перебьёте.

> А так будут видит время в тайм зоне сервера :(

А если не выставляют — укажите нужную им в postgresql.conf, как обычно.

WITH ins AS (
  INSERT INTO attendance
    (action, people_id, action_time)
  VALUES
    (p_action, p_people_id, p_action_time)
  RETURNING *
)

OPEN result_cursor FOR SELECT * FROM ins;
RETURN result_cursor;

Выдает:

ERROR:  syntax error at or near "OPEN"
LINE 41:  OPEN result_cursor FOR SELECT * FROM ins;
          ^
SQL state: 42601
Character: 1175

Неужели это невалидный код?