именованный лок может использоваться в любых сценариях, фреймворк никак не ограничивает; например, для того, чтобы задачи определенного типа не могли исполняться параллельно, только по одной штуке на единицу времени

сейчас сделал так - в repeatable read пытаюсь вставить строку, где ключ - имя блокировки

вставилось - значит блокировка "захвачена"

Мой вам совет

Разберитесь в примере от Котерова

Что я скинул

да, я посмотрю обязательно, спасибо

это нормально, что статья от 2008 года?

для очередей есть ещё pgq

https://wiki.postgresql.org/wiki/PGQ_Tutorial

Нормально

вставилось - значит блокировка "захвачена"

У нас такой же солюшен через блокировки чтобы ограничивать параллельное исполнения кронджобов

С 2008 года ничего не поменялось тут кроме появления скиплокед

И пгку в 2008 тоже уже был

Ну и тоанзакционные адвизори добавились , да

Сделано через pg_try_advisory_lock/pg_try_advisory_unlock, когда лок захвачен для записи то мы ее выславлям в статус обработано

Почитайте тоже пример от Котерова

И что в статье не так чтоя написал? В середине сразу: "Собственно блокировка: pg_try_advisory_lock()"

Посмотрите про хак с дофильтровкой

Так как есть не очевидная гонка

Может быть

В подобных решениях

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

У кого получится тот и выиграл. Не самый оптимальный путь зато дубовый ?

Ну и ещё есть момент с выбором плана

В примере Котерова он тоже важен

Важно понимать когда pg будет функции выполнять из предиката

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

Например из за изменения статистики

Просто иногда когда хочешь сделать "идеально" то можно и ногу вот так прострелить как описывается в статье :)

Миша, а можно пример с гонкой пояснить? По моему, никто не гарантирует нам, что транзакция в сессии В закомитится раньше, чем начнется запрос A2. Соответственно, транзакция А не увидит изменений last_mail_at в транзакции В. И результирующая выборка А1 и А2 совпадет. Или я что-то упустил?

Всем привет! подскажите, делаю бекап базы: pg_dump —create unit -f unit.backup.sql в файле есть инструкция создать базу CREATE DATABASE unit WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8'; но при попытке восстановления ругается на то, что база не существует psql unit < unit.backup.sql psql: FATAL: database "unit" does not exist как восстановить базу без её создания?

Вы пытаетесь подсоединиться через psql к несуществующей БД. Соединяйтесь к существующей.

Вы пытаетесь подсоединиться через psql к несуществующей БД. Соединяйтесь к существующей.

так я пытаюсь восстановить базу которой нет

У вас коннект к созданной БД в дампе есть?

У вса текстовый дамп, который из команд состоит. Вы его натравливаете на обычный psql.

У вас коннект к созданной БД в дампе есть?

дамп делал так, как может быть коннект если я пытаюсь восстанавливать несуществующую базу?

pg_dump —create unit -f unit.backup.sql

У вса текстовый дамп, который из команд состоит. Вы его натравливаете на обычный psql.

там же есть CREATE DATABASE unit WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';

может всё таки pg_restore?

Вот там же посмотрите инструкцию соединения с БД которая в команде create создается. Она там есть?

может всё таки pg_restore?

он дамп от pg_dump не ресторит же

Вот там же посмотрите инструкцию соединения с БД которая в команде create создается. Она там есть?

$ cat unit.backup-create.sql — — PostgreSQL database dump — — Dumped from database version 9.6.3 — Dumped by pg_dump version 9.6.3 SET statement_timeout = 0; SET lock_timeout = 0; SET idle_in_transaction_session_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = on; SET check_function_bodies = false; SET client_min_messages = warning; SET row_security = off; — — Name: unit; Type: DATABASE; Schema: -; Owner: postgres — CREATE DATABASE unit WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8'; ALTER DATABASE unit OWNER TO postgres; \connect unit SET statement_timeout = 0; SET lock_timeout = 0; SET idle_in_transaction_session_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = on; SET check_function_bodies = false; SET client_min_messages = warning; SET row_security = off; — — Name: plpgsql; Type: EXTENSION; Schema: -; Owner: — CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog; — — Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner: — COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; — — PostgreSQL database dump complete —

> \connect unit Во!!!

Есть же

Вот там же посмотрите инструкцию соединения с БД которая в команде create создается. Она там есть?

\connect unit

да, после создания

psql < unit.backup.sql Спасёт вас :)

psql < unit.backup.sql Спасёт вас :)

без указания базы?

Без unit. unit - имя БД

Коллеги, снова вопрос: Есть таблица размером 2.5GB. В нее идет постоянная запись, все инсерты обрабатываются триггером (В триггере есть update и delete из таблицы). Пишется раз в минуту примерно 2500 записей. Есть несколько составных индексов и один индекс по условию. Вот если делать выборку с индексом по условию то запрос выполняется оооочень долго.

без указания базы?

Да. Вы должны соединяться к любой существующей БД на кластере. По умолчанию это postgres

Коллеги, снова вопрос: Есть таблица размером 2.5GB. В нее идет постоянная запись, все инсерты обрабатываются триггером (В триггере есть update и delete из таблицы). Пишется раз в минуту примерно 2500 записей. Есть несколько составных индексов и один индекс по условию. Вот если делать выборку с индексом по условию то запрос выполняется оооочень долго.

К сожалению, все телепаты на данный момент заняты

К сожалению, все телепаты на данный момент заняты

какие вводные нужны еще?

Запрос, план. Желательно explain (analyze, buffers)

если explain analyze делать, то инсерты в очередь становятся

что критично

Табличка CREATE TABLE public.flowlog ( timestart integer, timeend integer, insideip inet, outsideip inet, startport integer, endport integer )

CREATE INDEX active_idx ON public.flowlog USING btree (timeend) WHERE timeend = 0;

индекс

Выполнение запроса останавливает инсерты? Селект в PG неблокирующий. Что-то вы заливаете

ну выполняются дольше в смысле

Запрос хотя бы покажите

select * from flowlog where timeend = 0

выполняется уже 2 минуты

а explain?

А план? Есть подозрение, что ваш индекс не используется

не используется, или опух

размер 418 МБ

ну, это не на две минуты, если косяков в дисковой подсистеме нет

Я думаю, индекс перестраивается постоянно

это возможно

timeend постоянно меняется

50000 строк выглядит как правда?

50000 строк выглядит как правда?

да, это нормально

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

не меняйте timeend :)

еще предложения?

вообще надо explain (analyze, verbose, buffers) хоть раз дождаться и посмотреть в buffers

Страшный триггер

BEGIN IF NEW.timeend > 0 THEN DELETE FROM flowlog WHERE timestart = NEW.timestart AND timeend = 0 AND insideip = NEW.insideip AND outsideip = NEW.outsideip AND startport = NEW.startport AND endport = NEW.endport; END IF; UPDATE flowlog SET timeend = NEW.timestart WHERE timestart < NEW.timestart AND timeend = 0 AND outsideip = NEW.outsideip AND startport = NEW.startport AND endport = NEW.endport; RETURN NEW; END;

это на каждый инсерт

подозреваю, что в индексе лежит очень много отсылок на старые страницы и неподходящие под условия таплы, и перебрать их занимает время

по-другому я не знаю как решить проблему актуальности данных

в идеале в схеме не должно быть апдейтов

таблица, в которой каждую строку будут апдейтить - кошмар MVCC

delete + insert?

нет, просто два инсерта и тип "начало" и "конец"

вот тут главная проблема

опишу сейчас

Есть сенсор flow. По UDP прилетают пачки данных о старте сессии - timeend = 0 и завершени сесии , timeend = unix_time

udp бывают теряются, соотвественно приходится изощряться

Условие апдейта расчитано на то, чтобы в любом случае перекрыть активную сессию

делай это на чтении во view, например, оконными функциями

т.е. сделать insert only таблицы и все остальное отсекать группировками?

да