а в логах базы откуда берется такая ошибка?

Хмм... оттуда и берётся (её выдаёт PostgreSQL, а не pgbouncer, естественно). Так вы пробовали отловить?

Хмм... оттуда и берётся (её выдаёт PostgreSQL, а не pgbouncer, естественно). Так вы пробовали отловить?

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

так в issue по ссылке выше говорилось что ошибка связана с работой приложения через pgbouncer в transaction mode

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

А у вас логируются только ошибки? Тогда хуже... но, тем не менее, можно попробовать отловить "SET TRANSACTION READ ONLY;" (и т.п.) в приложении сейчас (включив логирование), в надежде на то, что это обычно делает либо используемый им драйвер, либо оно само.

так в issue по ссылке выше говорилось что ошибка связана с работой приложения через pgbouncer в transaction mode

Так у вас всё то же, но только C++, я правильно понял?

pgbouncer

через JetBrain-овскую IDE к базе коннектитесь? они ставят read-only на сессию по умолчанию.

Так у вас всё то же, но только C++, я правильно понял?

не совсем, приложение спокойно себе работало и в какой то момент несколько транзакций завалилось с ошибкой cannot execute UPDATE in a read-only transaction и после перезапуска все вновь стало нормально

через JetBrain-овскую IDE к базе коннектитесь? они ставят read-only на сессию по умолчанию.

причем здесь jetbrains если речь идет о приложении?

Всем привет. Такой вопрос... А реально ли постгресовому RETURNING присобачить алиас для полей?

ORM требует для маппинга (по крайней мере для простого пути)

причем здесь jetbrains если речь идет о приложении?

при том, что они могут делить один пул в pgbouncer-е

вы спросили, кто-нибудь сталкивался. я сталкивался с вот таким, как описал.

Что тотипа RETURNING alias.id, ... ?

при том, что они могут делить один пул в pgbouncer-е

ну ок, но по какой причине одна транзакция может влиять на другую транзакцию?

read-only на сессию, а не транзакцию.

полагаю, PostgreSQL возвращает одинаковую ошибку, даже если речь не о конкртеной транзакции.

ну ок, но по какой причине одна транзакция может влиять на другую транзакцию?

А причём тут "одна на другую"? Вроде в https://github.com/pgbouncer/pgbouncer/issues/224 достаточно подробно описано, в _чём именно_ причина, почему вы думаете, что ваше приложение / драйвер не делает того же?

это исключили

Т.е. как вы это исключили?

Т.е. как вы это исключили?

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

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

Так кроме кода разработчика есть ещё код драйвера, вы туда смотрели?

нашли косяк, чувак подключился через jetbrains в read-only режиме на порт баунсера

ух ты, у нас есть телепаты!

всем спасибо

Что тотипа RETURNING alias.id, ... ?

Прямо из https://www.postgresql.org/docs/current/static/sql-insert.html : [ RETURNING * | output_expression [ [ AS ] output_name ] [, ...] ]

Прямо из https://www.postgresql.org/docs/current/static/sql-insert.html : [ RETURNING * | output_expression [ [ AS ] output_name ] [, ...] ]

Я кстати по-другому сделал в итоге. INSERT INTO tbl AS alias

Так тоже оказывается можно )

Скажите, правильно ли будет решить следующую задачу через рекурсивные запросы. Если коротко то нужно генерировать номера для контр-агентов. Пример номера: 70468 где 7 это как бы "глобальный" неймспейс, "04" это закодированная буква D латинского алфавита, а 68 это просто 68 свободный в базе с такими же комбинациями на букву D в неймспейсе 7. Когда Последние две цифры переваливают за 99, то вместо 7 надо выбирать 8 и смотреть сколько контр-агентов под номером 04 и брать последнийсвободный саб-айди, например 01 если это первый контр-агентв неймспейсе 8. Т.е. его конечный id будет 80401

банальный инкремент? о_0

Всего таких глобальных неймспейсов может быть три: 7, 8 и 9. Если ни в одном для него места нет — то выбрасываем ошибку

какие-то странные сложности

Просто инкремент нельзя, перечитай еще раз ) Все это должен делать 1 SQL запрос )

я прочитал "генерить"

И уметь переключать доступные неймспейсы среди 7, 8 и 9

про селекты ни слова

Да, генерить, то максимальный id в группе 7 это 72699

Дальше 82699

И последний это 92699

три сиквенса со start и end

Решал подобную задачу, в итоге делал в коде приложения

И как же мне перескакивать на неймспейс 8 если для буквы Z все занято?

один сиквенс отвалится

а вообще да, бред такое в бд делать

Так он валиден для других букв )

Мне надо просто атомарно

Чтобы блокировками не обкладываться

не стоит всякий бред на базу перекладывать, пускай это делает аппликейшен

Какая разница где "бред" лежит?

большая

Мне надо просто атомарно

я использовал сиквенс и в приложении преобразовывал его значение

а непрерывность последовательности важна? тогда сиквенсы не подходят

Да, тут оно может быть непоследовательно

Это же контрагенты

так допускаются пропуски или нет?

В пределах 701XX не допускаются

Остальное может скакать как попадет

По сути для комбинации первых трех чисел ­ — два последних это некий сиквенс

в общем, вы правы - это можно сделать подзапросами

Без рекурсивных не обойтись? Или можно? Пока понять не могу

Именно вот этот "перескок" чтобы реализовать

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

перескок? ткните еще раз в него

70199 - последний id в базе для буквы A для неймспейса 7.

Добавляю еще длябуквы А. Будет поправилам — 80101

8(namespace)01(char position)01(seq)

A=01, B=02... Z=26

вам проще сразу таблицу меппинга сделать наверно

А вот подскажите - pgbarman так и не научился сжимать base backup?

и если нет - какова формула подсчёта необходимого места на диске для его использования?

вам проще сразу таблицу меппинга сделать наверно

Чего на что?

вводные: есть некоторое количество БД размером от 50GB до 1Tb.

хочется делать не менее 4 точек восстановления в день

ну и соотв. хранить промежуточные валы

Чего на что?

входящих данных на исходящие

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

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

В смысле вот так: SELECT * FROM generate_series(1, 26) AS g(gid), generate_series(1, 99) AS t(tid) ?

Получится около 7к строк как раз. Или еще часть с неймспейсом?

наоборот, наймспейс включить, а seq не генерировать

А

дальше: - найти минимальный свободный seq в каждом префиксе - отсеять те, где seq = 99 - найти минимальный из оставшихся результатов - увеличить в нем seq на единицу - PROFIT

Щас буду пробовать. Спасибо за подгон )

И да, клянусь, эту накоманию не я придумал!

вообще, че-то мы перемудрили.

Мне иногда кажется каждый раз, когда что-то касается бухгалтерии — начинается какой-то ад

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

я правильно понял, что ваш номер - это XYZ, где X - от 7 до 9; Y - от 01 до 26; Z - от 0 до 99?

я правильно понял, что ваш номер - это XYZ, где X - от 7 до 9; Y - от 01 до 26; Z - от 0 до 99?

Все верно

X = 7 + n / 2600 Y = 1 + (n % 2600) / 100 Z = n % 100

Грузовик математиков подъехал?)

n - текущее значение сиквенса

n - текущее значение сиквенса

У вас в Z нули получаются иногда из за деления по модулю

А, my bad. Я выше тоже не так подтвердил ?

1-99

X = 7 + n / 2574 Y = 1 + (n % 2574) / 99 Z = 1 + n % 99

n % 99 + 1

Ну да )