Между тем, когда открыл транзакцию и когда её закоммитил или откатил, коннект не закрывай просто. Я об этом

Всё-таки решили разобраться, можно ли сделать добавление записей из другого воркера в более элегантном, правильном и оптимальном стиле.
Таблицу message заполняет один воркер, который отправляет пару keyword, message_id в другой воркер. И второй воркер должен создавать следующие записи в базе постгреса:
1. Запись в таблицу type, если её нет.
2. Запись в таблицу keyword, если её нет.
3. Запись в таблицу message-keyword, если её нет.
Проблема заключается в том, что записи добавляются в базу параллельно, и может возникнуть случай, когда на любом из шагов 1-3 словим IntegrityError. В этом случае, необходимо либо пропустить какой-то шаг 1-3 (т. к. данные по этому записи уже есть) и создать недостающие связи, если такие есть, либо отправить задачу на Retry, где в самом начале работы воркер проверяет, существует ли keyword в базе.
В текущей реализации никаких on_conflict_do не используются, а используются savepoint перед каждым из шагов 1-3. Если возникла ошибка, то делаем rollback и идём дальше. Насколько это хорошо или плохо? Как это сделать более правильно? Единственное, что у меня на уме — это то, что необходимо сделать все эти добавления одной транзакцией, потому что в случае неудачи в воркере (хоть данные сейчас и записываются в самом конце работы воркера, но логика работы может измениться в скором времени) данные в базе должны быть в том виде, в котором они были до выполнения задачи.

Всё-таки решили разобраться, можно ли сделать добавление записей из другого воркера в более элегантном, правильном и оптимальном стиле.
Таблицу message заполняет один воркер, который отправляет пару keyword, message_id в другой воркер. И второй воркер должен создавать следующие записи в базе постгреса:
1. Запись в таблицу type, если её нет.
2. Запись в таблицу keyword, если её нет.
3. Запись в таблицу message-keyword, если её нет.
Проблема заключается в том, что записи добавляются в базу параллельно, и может возникнуть случай, когда на любом из шагов 1-3 словим IntegrityError. В этом случае, необходимо либо пропустить какой-то шаг 1-3 (т. к. данные по этому записи уже есть) и создать недостающие связи, если такие есть, либо отправить задачу на Retry, где в самом начале работы воркер проверяет, существует ли keyword в базе.
В текущей реализации никаких on_conflict_do не используются, а используются savepoint перед каждым из шагов 1-3. Если возникла ошибка, то делаем rollback и идём дальше. Насколько это хорошо или плохо? Как это сделать более правильно? Единственное, что у меня на уме — это то, что необходимо сделать все эти добавления одной транзакцией, потому что в случае неудачи в воркере (хоть данные сейчас и записываются в самом конце работы воркера, но логика работы может измениться в скором времени) данные в базе должны быть в том виде, в котором они были до выполнения задачи.

“как” зависит от того “что” у вас там…

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

ребят можете объяснить как написать этот запрос ?

При анализе продаж книг выяснилось, что наибольшей популярностью пользуются книги Михаила Булгакова, на втором месте книги Сергея Есенина. Исходя из этого решили поднять цену книг Булгакова на 10%, а цену книг Есенина - на 5%. Написать запрос, куда включить автора, название книги и новую цену, последний столбец назвать new_price. Значение округлить до двух знаков после запятой.

мой запрос:

SELECT author, title, 
                ROUND(
                    IF(author = 'Булгаков М.А.', price * 1.1, 
                        IF(author = 'Есенин С.А.', price * 1.05, price)), 2) AS new_price 
FROM book;

ругается No function matches the given name and argument types. You might need to add explicit type casts.

case when author=‘Есенин’ then price *1.05 when author=‘Булгаков’ then price * 1.1 else price end

Подскажите плз, если приложение обращается к information_schema как к xxx.information_schema, можно ли средствами PostgreSQL сделать что-то типа симлинка, чтобы при обращении к xxx.information_schema шло обращение к information_schema? Через проксирование запроса решение так себе.

Подскажите плз, если приложение обращается к information_schema как к xxx.information_schema, можно ли средствами PostgreSQL сделать что-то типа симлинка, чтобы при обращении к xxx.information_schema шло обращение к information_schema? Через проксирование запроса решение так себе.

Переписал транзакцию с on_conflict_do_nothing(), вроде всё работает как надо. Запущу на ночь воркеры, поглядим на результат. Но перед уходом хочу поинтересоваться, нормальное ли это поведение:
Воркеры обрабатывали в самом начале под ~1,500 сообщений в секунду, а затем стабильно ~600, что отражается и на графиках транзакций бд. И ещё непонятный скачок до 20,000 транзакций в секунду. Напомню, что в pgbouncer на данный момент стоят настройки: pool_mode=transaction, default_pool_size=20, max_client_conn=2000