30 сек - это я с лихвой взял значение прям по таймаут

Обычно ждут секунд пару, а потом "ничего не работает, всё сломалось"

> Вы сейчас про savepoint вы мне пытаетесь рассказать? Нет. Я говорю о том, как приложения обязаны обращаться с данными и реагировать на SQL states, возвращаемые СУБД, чтобы сохранять ACID-свойства. В данном случае, транзакции, которые получили serialization failure (и подобные states), должны автоматически повторяться. > Или про всякие мулечки в питоне и прочих? Какие "мулечки"? Это базовые требования работы с любой ACID (SQL) СУБД. ;) Если кто-то не работает с ними так, как положено, никакого ACID у Вас не будет в любой, и это уже только его проблемы. > протокол обработки подобных исключительных ситуаций .... Название у протокола-то есть? )) Под "протоколом" я имел в виду ряд основных принципов. Не знаю, есть ли у них название...

Если у принципов нет названий - очень похоже, что это доморощенные принципы

Обычно ждут секунд пару, а потом "ничего не работает, всё сломалось"

вы вообще о других вещах говорите

UPDATE table SET TheColumn = regexp_replace( TheColumn, '#слово(2)?([^ ]+)?', '', 'g' ) это на вскидку, попробуйте на тестовой таблице

Спасибо помогло

вы вообще о других вещах говорите

Поясните

Поясните

как связаны retry при serializable read и ожидание для юзера? если вы вот так юзерские данные пишите, то скорее всего делаете что-то не так

и read commited вам достаточно

Т.е. вместо того, чтобы честно показать ошибку, ваше приложение будет бесконечно долбиться к занятым данным и "висеть"? Это вы называете бест прэктис в архитектуре БД? Это уж точно антитребования какие-то

О-хо-хо. :( Т.е. Вы этих принципов не знаете. :( (А ведь это не какие-то там "best practice", это просто основы.) Я поэтому в начале дискуссии и спрашивал, где Вы (всему) этому научились. > А если SLA отдачи всей страницы 30 секунд СУБД общего назначения не являются real-time, и никаких гарантий времени отклика в принципе не дают. Если у кого-то есть такое требование, ему придётся использовать какой-то другой инструмент, в худшем случае. > Если у принципов нет названий - очень похоже, что это доморощенные принципы Да Вы что? ;) Вот из "доморощенного" ISO SQL: "4.36.5 Implicit rollbacks The execution of a <rollback statement> may be initiated implicitly by an SQL-implementation when it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions. When this error occurs, an exception condition is raised: transaction rollback — serialization failure." А вот описание принципов из "доморощенной" документации PostgreSQL: "When an application receives this error message [serialization failure], it should abort the current transaction and retry the whole transaction from the beginning." "...it is important that any data read from a permanent user table not be considered valid until the transaction which read it has successfully committed..." Ну и т.д. И вообще в любой многопользовательской ACID SQL СУБД действуют всё те же принципы.

@alexfoxsy будет жить. Поприветствуем!

господа, подскажите, вот надо запилить сложную процедуру на plpgsql - она берёт данные из разных таблиц, ковыряет их и пишет результат в другие таблицы. Чтобы не путаться в коде, разбиваю её на разные функции. И возникает такая ситуация, что "родительская" функция делает определенные вычисления, в результате которых получается несколько переменных, затем вызывает в цикле дочернюю функцию, которая использует эти переменные. Так вот - как их передать эти переменные, чтобы не пересчитывать их каждый раз при вызове "дочерней" функции в цикле? Создать виртуальную таблицу и передавать её имя? Или крупные объекты передаются по ссылке? Есть ли там что-то вроде copy-on-write optimization?

господа, подскажите, вот надо запилить сложную процедуру на plpgsql - она берёт данные из разных таблиц, ковыряет их и пишет результат в другие таблицы. Чтобы не путаться в коде, разбиваю её на разные функции. И возникает такая ситуация, что "родительская" функция делает определенные вычисления, в результате которых получается несколько переменных, затем вызывает в цикле дочернюю функцию, которая использует эти переменные. Так вот - как их передать эти переменные, чтобы не пересчитывать их каждый раз при вызове "дочерней" функции в цикле? Создать виртуальную таблицу и передавать её имя? Или крупные объекты передаются по ссылке? Есть ли там что-то вроде copy-on-write optimization?

Да делали бы Вы как удобнее / логичнее, IMHO. Вот у Вас уже есть проблемы с производительностью? > Создать виртуальную таблицу и передавать её имя? Кстати, что такое "виртуальная таблица"? Temporary? Или переменная/параметр композитного типа?

господа, подскажите, вот надо запилить сложную процедуру на plpgsql - она берёт данные из разных таблиц, ковыряет их и пишет результат в другие таблицы. Чтобы не путаться в коде, разбиваю её на разные функции. И возникает такая ситуация, что "родительская" функция делает определенные вычисления, в результате которых получается несколько переменных, затем вызывает в цикле дочернюю функцию, которая использует эти переменные. Так вот - как их передать эти переменные, чтобы не пересчитывать их каждый раз при вызове "дочерней" функции в цикле? Создать виртуальную таблицу и передавать её имя? Или крупные объекты передаются по ссылке? Есть ли там что-то вроде copy-on-write optimization?

Возможно стоит посмотреть в сторону IMMUTABLE или materialized view

Да делали бы Вы как удобнее / логичнее, IMHO. Вот у Вас уже есть проблемы с производительностью? > Создать виртуальную таблицу и передавать её имя? Кстати, что такое "виртуальная таблица"? Temporary? Или переменная/параметр композитного типа?

проблем нет, более того, забавно - но эту "подсистему" я делаю с одной целью - чтобы можно было частично обновлять материализованный вид, то есть например, есть у нас 200 стран и 100 тысяч городов. в каждой стране нужно посчитать сколько всего городов, и сколько городов, у которых есть те или иные свойства. соответственно, когда меняется запись города - нет смысла обновлять весь материализованный вид, можно обновить только запись одной страны

Возможно стоит посмотреть в сторону IMMUTABLE или materialized view

да, видел в доке, не совсем то, но вероятно тоже пригодится

наверное тогда сделаю действительно как удобнее - в любом случае, ждать несколько минут хуже чем ждать лишние 500мс

проблем нет, более того, забавно - но эту "подсистему" я делаю с одной целью - чтобы можно было частично обновлять материализованный вид, то есть например, есть у нас 200 стран и 100 тысяч городов. в каждой стране нужно посчитать сколько всего городов, и сколько городов, у которых есть те или иные свойства. соответственно, когда меняется запись города - нет смысла обновлять весь материализованный вид, можно обновить только запись одной страны

> чтобы можно было частично обновлять материализованный вид Так в случае настоящего materialized view у Вас и выбора-то нет... Или это на самом деле таблица + триггеры, которая работает как matview?

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

> чтобы можно было частично обновлять материализованный вид Так в случае настоящего materialized view у Вас и выбора-то нет... Или это на самом деле таблица + триггеры, которая работает как matview?

да, именно так - триггеры, таблицы изменений (там у меня типа "библиотека" с функциями observe_table(table_name text, и т.д.) которая создаёт триггеры и таблицу под изменения и recalc_changed(...), которая смотрит базу и обновляет)

да, именно так - триггеры, таблицы изменений (там у меня типа "библиотека" с функциями observe_table(table_name text, и т.д.) которая создаёт триггеры и таблицу под изменения и recalc_changed(...), которая смотрит базу и обновляет)

Может, у Вас проблемы из-за слишком "общего" подхода ("observe_table(table_name text ...")? Обычно это (написание триггеров для обновления конкретных таблиц) не так, чтобы очень сложно...

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

да, в одной транзакции держу, причём прикол - там даже 3 режима вызова функции - 1. обновить всё независимо ни от чего, 2. просто посмотреть что подлежит обновлению, 3. обновить только если с последнего вызова не добавилось новых изменений, если они добавились - оборвать транзакцию и сообщить что мол, действие требует участия пользователя

Может, у Вас проблемы из-за слишком "общего" подхода ("observe_table(table_name text ...")? Обычно это (написание триггеров для обновления конкретных таблиц) не так, чтобы очень сложно...

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

прям так и просится сюда ООП фичи))

да, и при том на этом скрине даже нет таблиц "обслуживаемых компонентов" - они отдельно, в других схемах

да, и самое главное - там удобство очень крутое даётся с таким подходом - в обслуживаемой схеме создаются функции-хендлеры типа country_on_city_attached(), city_on_cnt_streets_changed() и т.д. подсистема ищет эти хендлеры по схемам и если находит, и при этом в таблицах есть какие-то изменения - вызывает нужные хендлеры. таким образом у нас отдельно "обслуживающая" логика и отдельно "клиентская"

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

как связаны retry при serializable read и ожидание для юзера? если вы вот так юзерские данные пишите, то скорее всего делаете что-то не так

Это вы Ярославу расскажите. Я как раз за это и топлю. А ему сериализацию подавай и не меньше

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

Yaroslav, зачем в аббревиатуре ACID буковку I отделили от буквоки C? Вообще под консистентностью я понимал всегда следующее: соблюдение констрейтов в базе (FK, not null, check).

Yaroslav, зачем в аббревиатуре ACID буковку I отделили от буквоки C? Вообще под консистентностью я понимал всегда следующее: соблюдение констрейтов в базе (FK, not null, check).

+++

Yaroslav, зачем в аббревиатуре ACID буковку I отделили от буквоки C? Вообще под консистентностью я понимал всегда следующее: соблюдение констрейтов в базе (FK, not null, check).

А ведь я уже отвечал. С примером.

А ведь я уже отвечал. С примером.

Можете на сообщение сослаться?

Можете на сообщение сослаться?

https://t.me/pgsql/104679

+++

Я в целом согласен с Ярославом)

Я в целом согласен с Ярославом)

Согласны, что изоляция определяет согласованность?

Согласны, что изоляция определяет согласованность?

Я же Вам уже писал, что все части ACID связаны. И примеры приводил...

Изоляция определяет область видимости данных, для транзакций, которые выполняются параллельно. Вот цель изоляции.

https://t.me/pgsql/104679

Как бы могли бы и не разделять C и I из-за этого. Сказали бы не full AID или не full ACD, если какие-то констрейты не соблюдаются.

Изоляция определяет область видимости данных, для транзакций, которые выполняются параллельно. Вот цель изоляции.

Да не в этом цель изоляции. Всякие там "области видимости данных" — это просто средство. Цель, собственно, в том, чтобы как-то изолировать. ;) Стандарт формализует эту цель как достижение сериализуемости, и всё.

#приоритезация_юзераф Друзья, фсех с панидельникам! Подскажите пожалуйста в какую сторону смотреть/что почитать Задача? : Нужна приоритезация доступа пользователей к базе, т.е. в случае когда фсе забыли позакрывать коннекты и исчерпали лимит, наши клиенты всегда могли зайти

Как бы могли бы и не разделять C и I из-за этого. Сказали бы не full AID или не full ACD, если какие-то констрейты не соблюдаются.

Так это разные вещи. Вот, допустим, база работает так, что по каскадным FK она действия не выполняет (ну вот так вот реализовано). При этом, допустим, транзакции полностью изолированы. А корректность данных всё равно не сохраняется. Или, наоборот, все явно прописанные в БД constraints соблюдаются, но возникают аномалии сериализации. И корректность данных всё равно не сохраняется.

Лимитировать количество соединений по-юзверно + баунсер

Да не в этом цель изоляции. Всякие там "области видимости данных" — это просто средство. Цель, собственно, в том, чтобы как-то изолировать. ;) Стандарт формализует эту цель как достижение сериализуемости, и всё.

Так изоляция и происходит за счет видимости, за счет того, какую версию тапла вам показывают.

Так это разные вещи. Вот, допустим, база работает так, что по каскадным FK она действия не выполняет (ну вот так вот реализовано). При этом, допустим, транзакции полностью изолированы. А корректность данных всё равно не сохраняется. Или, наоборот, все явно прописанные в БД constraints соблюдаются, но возникают аномалии сериализации. И корректность данных всё равно не сохраняется.

В смысле разные? консистентность данных - это их непротиворечивость. Сюда входят и fk и check и изоляция транзакции.

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

Вообщем, понятно, что вам это неизвестно, поскольку не вы стандарт SQL писали. Или я чего-то не знаю про вас?)

Давайте зайдем с другого бока. Вот у нас однопользовательская БД. Там работает один пользователь. Всё сериализовано. Как по вашему, она может быть не консистентной?

Так изоляция и происходит за счет видимости, за счет того, какую версию тапла вам показывают.

Во-первых, отчасти (есть ещё предикатные блокировки, и serialization failures, и deadlocks). Во-вторых, только в нашей СУБД. А другие вообще не обязаны использовать версии (да и блокировки, если уж на то пошло), и не обязаны обеспечивать какую-то видимость (не считая требуемого стандартом исключения lost updates). Т.е., если serialializability достигается, то уже всё равно, что и кому там было видно. ;)

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

Так я же уже приводил пример про каскадные FK. Т.е. constraints могут просто не поддерживаться полностью, даже с одним пользователем, why not. ;)

Давайте зайдем с другого бока. Вот у нас однопользовательская БД. Там работает один пользователь. Всё сериализовано. Как по вашему, она может быть не консистентной?

Да, может. См. предыдущее сообщение.

Да, может. См. предыдущее сообщение.

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

Лимитировать количество соединений по-юзверно + баунсер

а может чуть подробнее? ну или названия как это пишется по англицки pgbouncer detected! а вот юзверно остаётся загадкой )

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

Эээ... стоп. Давайте в словах не путаться. Особенно в случаях, когда consistency употребляется как термин, и когда — в "интуитивном" значении. Так вот, изоляция является частью обеспечения корректности данных.

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

И ещё, кстати: Вам не кажется, что Вы по умолчанию предполагаете, что у нас есть "волшебное" средство, которое автоматически позволяет "увидеть" базу в "настоящем" (что бы это ни значило) состоянии, несмотря на наличие конкурентных транзакций? А без SERIALIZABLE такого средства может и вообще не быть... ;)

Эээ... стоп. Давайте в словах не путаться. Особенно в случаях, когда consistency употребляется как термин, и когда — в "интуитивном" значении. Так вот, изоляция является частью обеспечения корректности данных.

Никаких интуитивных смыслов. Вам было дано четкое определение одного из основоположников теории БД. Примерно такого же как Кодд. Вы мне так и не объяснили чем консистентность в ACID отличается от таковой в CAP

Никаких интуитивных смыслов. Вам было дано четкое определение одного из основоположников теории БД. Примерно такого же как Кодд. Вы мне так и не объяснили чем консистентность в ACID отличается от таковой в CAP

> Никаких интуитивных смыслов. То есть, слов "консистентность", "согласованность", "корректность" в других смыслах никто из нас не употреблял? ;) > Вам было дано четкое определение одного из основоположников теории БД. Примерно такого же как Кодд. Ну-ну. Отчего же другие теоретики называют многие его воззрения, как минимум, экстремальными? ;) И "определение" это плохое. Во-первых: Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. А что мы оттуда можем считать, значит, неважно? И ещё, что значит, конкретно: must be valid according to ... triggers? > Вы мне так и не объяснили чем консистентность в ACID отличается от таковой в CAP Они вообще из разных иерархий. В CAP вообще никаких транзакций нет, а consistency определяется как linearilizability отдельных значений в распределённой системе, если я ещё правильно помню (мне эта тема не очень интересна, извините).

@anton_lar будет жить. Поприветствуем!

Выдаёт ошибку

Говорят такого файла нету

Говорят такого файла нету

Но файл именно там, проверял несколько раз, как решить?

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

Помести файл в друное место, наверно на каталог юзера прав нет И научись скрины делать)

Эм, каталог русскими буквами "Питон"

в винде вроде как можно полный путь до файла скопировать (shift и правый клик мыши по файлу)

Ребята, а кто как проверяет поднятие сервиса при автоматическом тесте бекапа ? ну то что он поднялся корректно ? парсинг лога или еще как ?

Помести файл в друное место, наверно на каталог юзера прав нет И научись скрины делать)

Теперь пишет permission denied

Теперь пишет permission denied

Паучье чутьё подсказывает, что у юзера, с которым запускается постргес, нет прав на доступ к файлам, которые, вероятно, созданы другим юзером.

Паучье чутьё подсказывает, что у юзера, с которым запускается постргес, нет прав на доступ к файлам, которые, вероятно, созданы другим юзером.

Как исправить?

Как исправить?

Проверить права на файл, например

@Molly_Malone будет жить. Поприветствуем!

Нужен совет как избавиться от кавычек

cursor2.execute('''SELECT chat_id FROM users_info WHERE %s ILIKE %s ''', (parameter_for_filter, filter ))

Где

parameter_for_filter='salon'

Получается

"SELECT chat_id FROM users_info WHERE 'salon' ILIKE 'g%' "

Буду весьма признателен

"SELECT chat_id FROM users_info WHERE 'salon' ILIKE 'g%' "

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

Это название столбца

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

если прописываю вместо айпишников * срабатывает, но это как-то небезопасно

Нужен совет как избавиться от кавычек

psycopg2 не позволяет вставлять идентификаторы без экранирования. Вам надо что-то вроде execute('select * where {} ilike %s'.format(sql.Identifier(parameter_for_filter)), (filter,))

У Вас PostgreSQL дожен слушать на три сетевых интерфейсах (адресах)? Или что именно не срабатывает?

У Вас PostgreSQL дожен слушать на три сетевых интерфейсах (адресах)? Или что именно не срабатывает?

да, если их прописать, то не слушает ничего, но если вставить звездочку, то все ок

psycopg2 не позволяет вставлять идентификаторы без экранирования. Вам надо что-то вроде execute('select * where {} ilike %s'.format(sql.Identifier(parameter_for_filter)), (filter,))

задавался сегодня таким же вопросом, если через sqlalchemy делать, то можно через text()