спасите помогите 🙂

Использую короткоживущие пользовательские сессии (облако), т.е. пользователи создаются с рандомными доступами на короткий срок, приводятся в нужный вид серией команд и отдаются приложению.

Пользователь создается так:

CREATE USER "{{name}}" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
GRANT project_rw TO "{{name}}";
ALTER ROLE "{{name}}" SET role project_rw;
ALTER ROLE "{{name}}" SET search_path TO django, public;

Сделал SET role project_rw чтобы объекты создаваемые пользователем (к примеру из автоматических миграций базы) принадлежали роли, а не текущему юзеру, иначе их потом никто не сможет поправить в другой миграции другим пользователем.  Но этого не происходит 🙁 созданные таблицы привязались к юзернейму. Что я делаю не так?

В принципе способна, для одностайтментовых транзакций. Другое дело - есть ли в этом большой смысл... И еасколько хорошо  по разному вести себя на "простых "и "сложных" транзакциях.

UPDATE something SET current_time = '09:45'

Повторите автоматически. Так, "в принципе". ;)

Здравствуйте! Подскажите, пожалуйста, как грамотно решить проблему планирования осуществления некоторых действий для нескольких БД в одном кластере? Просто pg_cron может работать только для одной БД, к сожалению.

А что с этим не так?

Т.е. когда она выполнится (после десятка повторов, к примеру) в 9:57 — это нормально? ;)

Чего только выше нет! А эта декларация проверяется калькулятором  или даже листочком с ручкой. Надо только примерно прикинуть при каком значении deadlock_timeout и примерной вероятности дедлока бекенды перестанут успевать обслуживать клиентов.

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

Т.е. когда она выполнится (после десятка повторов, к примеру) в 9:57 — это нормально? ;)

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

А "не декларация" (то, что такие повторы — часть нормальной работы) "проверяется" чтением учебников. :)

А "не декларация" (то, что такие повторы — часть нормальной работы) "проверяется" чтением учебников. :)

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

Чат, общетеоретический вопрос) А как вообще правильно:
- приложение отправляет запросы к таблицам, явно указывая схему
- приложение ничего не знает о схемах, всё рулится через search_path для роли под которой приложение работает.

Второй вариант авито упоминали на конференциях, когда выкатку новых фич порционно делали.
Ну а первый вариант... просто проще для дба?)

с точки зрения безопасности схему надо указывать явно. был даже секюрити релиз, чтобы предотвратить инъекции через создание “своих” объектов в схемах, который “раньше” в search_path.
если уверены в безопасности сервера, то этим можно пользоваться умышленно как раз для смены версий функционала

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

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

Поиск цикла в графе делается под эксклюзивной блокировкой. Вероятность того, что оба участника дедлока решат  сделать харакири достаточно мала.
Но есть другая более реальная проблема, которую мы действительно наблюдали.
И, вспомнив про неё, я склонен согласится, что в дедлок дететоре посгреса действительно есть деффект.
Под большой нагрузкой, если много транзакций конфликтуют за один и тот же ресурс (например table extension lock), то все они засыпают на этом локе и ... таймаут в них срабатывает примерно в одно и тоже  время. И все они начинают искать дедлок, для этого пытая взять ксклюзивную блокировку. И... Всё практически  встаёт.
Мы в ПгПро испытали несколько способов решить эту проблему:
1. Пытаться преварительно проверить наличие дедлка под шаред блокировкой.
2. Если кто-то уже ищет циклы в графе, то запретить ругим бэкендам заниматься дедлок детекшином
3. Запоминать в рётрах графа блокировки время последнего прохода и не ходить повторно по ним в течении какого-то времени

Если это время задаётся на бэкенде, то тут вообще ко всему прикопаться можно, потому что оно, конечно же, не будет иметь ничего общего с временем выполнения и временем, когда запрос на сервер отправили.