@winnie_ua вполне обошелся select distinct current_date,substr('121'||floor(random() * 999999999999999)::numeric,1,12)::numeric as qrcode,12 factory_id from generate_series(1,12000000)as sn limit 10000000;

а на слдующий день повторы будет, походу, не?

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

Это почему это асинхронная репликация не консистентна? Она может отставать от мастера, но с консистентностью там всё хорошо

Хмм... скажите, а откуда у Вас это убеждение? ;) (Я просто часто это читаю... стало любопытно, откуда все это берут.)

Хмм... скажите, а откуда у Вас это убеждение? ;) (Я просто часто это читаю... стало любопытно, откуда все это берут.)

Оттуда, что стендбай открытый на чтение косистентен. Или у вас другое мнение?

Оттуда, что стендбай открытый на чтение косистентен. Или у вас другое мнение?

Конситентен чему? (И да, и у меня, и у документации/реализации PostgreSQL, и у реальности другое "мнение". ;) )

Оттуда, что стендбай открытый на чтение косистентен. Или у вас другое мнение?

> Оттуда, что стендбай открытый на чтение косистентен. Так всё же, откуда у Вас это? Вы это прочитали где-то, или кто-то такое рассказывает?

> Оттуда, что стендбай открытый на чтение косистентен. Так всё же, откуда у Вас это? Вы это прочитали где-то, или кто-то такое рассказывает?

Вы не причитайте, а обоснуйте свое мнение. В доку ткните к конце концов

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

Вы не причитайте, а обоснуйте свое мнение. В доку ткните к конце концов

Я не "причитаю", а задаю Вам вопрос. Можете ответить? По доке: https://www.postgresql.org/docs/current/static/hot-standby.html (в конце) "The Serializable transaction isolation level is not yet available in hot standby. (See Section 13.2.3 and Section 13.4.1 for details.) An attempt to set a transaction to the serializable isolation level in hot standby mode will generate an error." Ну и см. по ссылкам.

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

Без кооперации со стороны других читающих — только LOCK TABLE. С кооперацией (т.е. кто не в ней не участвует, прочитает всё равно) — способы есть (SELECT ... FOR SHARE, advisory locks...).

Прекрасно. Т.е. БД с уровнем изоляции меньше Serializable вы считаете не консистентной?

ВСЕ сиквесны в моменте + 1000

Не еф случайно используете? Емнип с ним такое было. Или я с чем-то другим путаю

что есть ЕФ?

Прекрасно. Т.е. БД с уровнем изоляции меньше Serializable вы считаете не консистентной?

Да, конечно (потому что это так и есть). А Вы нет? ;)

что есть ЕФ?

Ентити фреймворк.

Значит точно не он

Была в каком-то чате такая трабла

у меня подозрение, что это как-то связано с логической репликацией

Не еф случайно используете? Емнип с ним такое было. Или я с чем-то другим путаю

Да это нормальное поведение PostgreSQL, вообще (а для логической репликации всё именно так, если я правильно помню). Т.е. клиенты ни при чём.

я посмотрел историю внедрения фич

Без кооперации со стороны других читающих — только LOCK TABLE. С кооперацией (т.е. кто не в ней не участвует, прочитает всё равно) — способы есть (SELECT ... FOR SHARE, advisory locks...).

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

и это появилось после внедрения логической репликации

Т.е. если Вам сойдёт асинхронная (и иногда неконсистентная) репликация, можно посмотреть на логическую репликацию, в самом деле. Вообще, тут нужно на точные требования смотреть.

мерси

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

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

FOR UPDATE, в таком случае. Опять-таки, все "читатели" должны так делать. Кто не делает — прочитает всё равно.

Да это нормальное поведение PostgreSQL, вообще (а для логической репликации всё именно так, если я правильно помню). Т.е. клиенты ни при чём.

Значит перепутал, спс

FOR UPDATE, в таком случае. Опять-таки, все "читатели" должны так делать. Кто не делает — прочитает всё равно.

FOR UPDATE В режиме FOR UPDATE строки, выданные оператором SELECT, блокируются как для изменения.

FOR UPDATE В режиме FOR UPDATE строки, выданные оператором SELECT, блокируются как для изменения.

Да. Поэтому выберет в данный момент времени только кто-то один. А Вам это вообще зачем, кстати?

Да, конечно (потому что это так и есть). А Вы нет? ;)

Нет. Уровень изоляции Read Commited вполне себе консистентен для 99% задач

Для особох случаев Repeatable read. Serializable нужен прямо вот совсем редко и это явно не High Load

Да. Поэтому выберет в данный момент времени только кто-то один. А Вам это вообще зачем, кстати?

Расчётная задача с попыткой распараллелить вычисления. В таблице сотни тысяч строк. Нужно перебрать все строки и в каждой строке произвести расчёты для ячейки. Расчёты для каждой строки зависят от данных в других строках из этой же таблицы. Если я распараллелю этот процесс, то есть опасность, что расчёты будут происходить некорректно. Возможно, я что-то неправильно делаю.

Нет. Уровень изоляции Read Commited вполне себе консистентен для 99% задач

А эту статистику Вы где прочитали? Проблема тут в том, что почти все неспособны им правильно пользоваться в нетривиальных случаях. Поэтому и трудно определить, входит ли конкретная задача в "99%" или нет. :( > Serializable нужен прямо вот совсем редко А некоторые используют вот прямо всегда. ;) > это явно не High Load Почему? И, кстати, High Load что, автоматически подразумевает, что получение/сохранение некорректных данных иногда — это Ok?

Давайте договоримся о терминах. Вы что понимаете под согласованностью?

Расчётная задача с попыткой распараллелить вычисления. В таблице сотни тысяч строк. Нужно перебрать все строки и в каждой строке произвести расчёты для ячейки. Расчёты для каждой строки зависят от данных в других строках из этой же таблицы. Если я распараллелю этот процесс, то есть опасность, что расчёты будут происходить некорректно. Возможно, я что-то неправильно делаю.

А Вы уже уверены, что без "распараллелить" всё плохо? (Но, вообще, Вы уверены, что просто блокировать будет достаточно?)

Формулировка из Дейта (сорри, на английском): Consistency in database systems refers to the requirement that any given database transaction must change affected data only in allowed ways. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined database constraints.

Вот я не вижу, как Read commited противоречит этому определению.

А Вы уже уверены, что без "распараллелить" всё плохо? (Но, вообще, Вы уверены, что просто блокировать будет достаточно?)

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

Давайте договоримся о терминах. Вы что понимаете под согласованностью?

Корректность как выполняемых транзакций, так и читаемых данных при наличии конкурентной нагрузки. Короче, то, что написано в стандарте SQL в "Isolation levels of SQL-transactions" — т.е. serializability, конечно.

Вот я не вижу, как Read commited противоречит этому определению.

Read committed допускает аномалии (с которыми программисты должны героически бороться), очевидно. Т.е., если кто-то "широко закроет глаза" и будет писать на RC так, как если бы аномалий не было... добром это не кончится.

Ну вот как-то жили прекрасно в том числе на Оракл с Read Commited и ничего героического в этом не было. И БД была консистентна. Как раз сериализация - это боль и кровь. В том числе для программеров. Если вы включите сериализацию, большинство приложений просто рухнет.

А у вас в мониторинг графики не выводятся по этим параметрам? Может проще дать ограниченный доступ?

Какой мониторинг?

Какой мониторинг?

Кто здесь? ))))) Извините ))) У вас нет мониторинга? Или вы спрашиваете, каким я пользуюсь?

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

То есть, у Вас одни рассчёты зависят от других, причём изменяют исходные данные? А один расчёт долгий? Если нет, можно ничего не блокировать, а SERIALIZABLE + повторять (в надежде, что конфликты будут редки).

То есть, у Вас одни рассчёты зависят от других, причём изменяют исходные данные? А один расчёт долгий? Если нет, можно ничего не блокировать, а SERIALIZABLE + повторять (в надежде, что конфликты будут редки).

Ну, ну очень долгий. Меньше чем десятая часть секунды. Но гарантия должна быть что не будет никаких проблем. Я так понимаю, что для данной задачи подход с транзакциями неверный. Потому что если в транзакции Изменили значение поля, то для расчёта других значений это полу будет фигурировать в ещё не изменённом виде, т.к. транзакция ещё не закрыта. А мне нужно производить расчёты уже на изменённых данных.

вот да, пойду прочту про Serializable

Ну вот как-то жили прекрасно в том числе на Оракл с Read Commited и ничего героического в этом не было. И БД была консистентна. Как раз сериализация - это боль и кровь. В том числе для программеров. Если вы включите сериализацию, большинство приложений просто рухнет.

> Ну вот как-то жили прекрасно в том числе на Оракл с Read Commited и ничего героического в этом не было. А, понятно. Т.е. есть люди, которые "прекрасно" жили на не-ACID СУБД, и до сих пор считают, что это нормально. Это вообще ровно то же самое, что "настоящий программист может писать на ассемблере... в любом языке программирования!" > И БД была консистентна. Вы знаете, у меня был большой личный опыт разбора некорретных данных в БД, вызванных этим "замечательным" подходом, и я в это просто больше не верю. > Как раз сериализация - это боль и кровь. В чём боль-то? > Если вы включите сериализацию, большинство приложений просто рухнет. И не удивительно. Это просто значит, что они не на неё рассчитаны, нет?

> Ну вот как-то жили прекрасно в том числе на Оракл с Read Commited и ничего героического в этом не было. А, понятно. Т.е. есть люди, которые "прекрасно" жили на не-ACID СУБД, и до сих пор считают, что это нормально. Это вообще ровно то же самое, что "настоящий программист может писать на ассемблере... в любом языке программирования!" > И БД была консистентна. Вы знаете, у меня был большой личный опыт разбора некорретных данных в БД, вызванных этим "замечательным" подходом, и я в это просто больше не верю. > Как раз сериализация - это боль и кровь. В чём боль-то? > Если вы включите сериализацию, большинство приложений просто рухнет. И не удивительно. Это просто значит, что они не на неё рассчитаны, нет?

Оракл не ACID???

Оракл не ACID???

Да, а что?

Да, а что?

Да, ой всё )))

вчера статью про оракл се 18 читал, прооорал че-то с нее.

Да, ой всё )))

Да всё так всё. ;)

Одновременно с этим, новый Product Manager по направлению Express Edition пообещал, что теперь и впредь мы будем наслаждаться новой версией XE практически одновременно с выпуском остальных редакций, т.е. также раз в год. Единственная разница будет состоять в том, что для XE не будет выпускаться патчей и исправлений безопасности, в отличие от SE и EE. Однакое, каждый следующий мажорный релиз XE будет включать в себя все исправления и изменения, сделанные в редакциях SE и EE за весь предыдущий год, что, конечно, не может не радовать. Особенно если учесть, что на протяжении 7 лет 11-ая версия XE также не получала никаких патчей и исправлений, но всё равно была сильно востребована у комьюнити.

вот на этом абзаце можно было закончить

7 лет без патчей, но мы готовы дальше жрать дерьмо и рады

Вообще, способность Oracle бессовестно лгать, что их СУБД "ACID / ISO SQL сompliant", весьма радует. ;) Ещё веселее читать их "обоснования" (мы не умеем читать^H^H^H понимаем стандарт альтернативно, и, поэтому...).

Вообще, способность Oracle бессовестно лгать, что их СУБД "ACID / ISO SQL сompliant", весьма радует. ;) Ещё веселее читать их "обоснования" (мы не умеем читать^H^H^H понимаем стандарт альтернативно, и, поэтому...).

Я выше привел определение (не своё :) консистентности, в котором 1) нет ни слова об уровнях изоляции 2) четко определено понятие корректных данных 3) четко сказано, что все аномалии - половые сложности программистов. Если в ISO SQL есть определение консистентности через уровни изоляций, то прошу его предъявить с указанием четко пункта, где оно живет

Я выше привел определение (не своё :) консистентности, в котором 1) нет ни слова об уровнях изоляции 2) четко определено понятие корректных данных 3) четко сказано, что все аномалии - половые сложности программистов. Если в ISO SQL есть определение консистентности через уровни изоляций, то прошу его предъявить с указанием четко пункта, где оно живет

> 3) четко сказано, что все аномалии - половые сложности программистов. Не сказано. Вы внимательно его прочитали? > Если в ISO SQL есть определение консистентности через уровни изоляций, то прошу его предъявить с указанием четко пункта, где оно живет Там есть определение поведения уровней изоляции. Соотношение их с консистеностью, как мне кажется, "вне" того, что должен определять стандарт (ожидается, что у читателей есть образование в соответствующей области... в которой это одно из базовых понятий).

А в pgAdmin4 можно как то посмотреть зависшие сесии? или в любой другой среде разработки?

А в pgAdmin4 можно как то посмотреть зависшие сесии? или в любой другой среде разработки?

на вкладке Dashboard

на вкладке Dashboard

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

У меня просто 2 Бд а сессии показываются только из одной

ну так выбери вторую БД в меню слева (или весь сервер)

ну так выбери вторую БД в меню слева (или весь сервер)

спасибо

А как установить отладчик в pgAdmin4 а то ругается на создайте расширение pldbgapi

> 3) четко сказано, что все аномалии - половые сложности программистов. Не сказано. Вы внимательно его прочитали? > Если в ISO SQL есть определение консистентности через уровни изоляций, то прошу его предъявить с указанием четко пункта, где оно живет Там есть определение поведения уровней изоляции. Соотношение их с консистеностью, как мне кажется, "вне" того, что должен определять стандарт (ожидается, что у читателей есть образование в соответствующей области... в которой это одно из базовых понятий).

Вот у меня стандарт 2013 года. В документе over 1500 страниц ни одного упомининия слова consistency. То что вы consistency притягиваете к isolation - это ваше личное изобретение

Вот у меня стандарт 2013 года. В документе over 1500 страниц ни одного упомининия слова consistency. То что вы consistency притягиваете к isolation - это ваше личное изобретение

> Вот у меня стандарт 2013 года. 2011, в смысле? > В документе over 1500 страниц ни одного упомининия слова consistency. Стандарт и не должен определять такие понятия. > То что вы consistency притягиваете к isolation - это ваше личное изобретение Вообще нет. И, кстати, чем больше я смотрю на это "определение" Дейта, тем меньше оно мне нравится. Наверное, оно вырвано из какого-то контекста, с корнем. ;)

кто-нибудь пробовал накатить на ubuntu 18 phpPgAdmin?

в целом, это штука работает?))

в целом работает

в целом работает

это же мне ответ?)

ща просто вместо pgadmin4 буду ставить

не зашла че-т

в целом, это штука работает?))

с 9-той версией работала, с 10-кой не хочет.

с 9-той версией работала, с 10-кой не хочет.

я тут узнал, что последняя версия 2013го года, так что вопрос снят

я так глубоко её не копал, она с ISP консолью ставилась автоматом.

> Вот у меня стандарт 2013 года. 2011, в смысле? > В документе over 1500 страниц ни одного упомининия слова consistency. Стандарт и не должен определять такие понятия. > То что вы consistency притягиваете к isolation - это ваше личное изобретение Вообще нет. И, кстати, чем больше я смотрю на это "определение" Дейта, тем меньше оно мне нравится. Наверное, оно вырвано из какого-то контекста, с корнем. ;)

Вот вам ещё аргумент. Аббревиатура ACID, которой вы тут щеголяете, расшифровывается: Atomicity Consistency Isolation Durability Как видно, согласованность - отдельная от изоляции характеристика. Балее того, CAP-базы, которые Consistency Availability Partition tolerance обеспечивают согласованность (О, УЖАС!!!) без уровней изоляции.

Вот вам ещё аргумент. Аббревиатура ACID, которой вы тут щеголяете, расшифровывается: Atomicity Consistency Isolation Durability Как видно, согласованность - отдельная от изоляции характеристика. Балее того, CAP-базы, которые Consistency Availability Partition tolerance обеспечивают согласованность (О, УЖАС!!!) без уровней изоляции.

Эээ... аргумент в пользу чего? > Аббревиатура ACID, которой вы тут щеголяете, расшифровывается: Я уже как-то запутался, что именно Вы пытаетесь обосновать. Аббревиатуры ACID тоже нет в стандарте, кстати. ;) > Как видно, согласованность - отдельная от изоляции характеристика. Балее того, CAP-базы, которые Да, отдельная, и это правильно. Т.к. можно нарушать constistency, не нарушая isolation. Например, тупо игнорируя некоторые constraints (или игнорируя их в некоторых случаях). (Я слышал, что MySQL когда-то поступал именно так.) > обеспечивают согласованность (О, УЖАС!!!) без уровней изоляции. В CAP этот термин имеет совершенно другое значение, "О, УЖАС!!". :)

встретились два DBA в баре...

встретились два DBA в баре...

О, УЖАС!!!

О, УЖАС!!!

Без уровней изоляции

ну хоть разнополые, раз уж без изоляции?

Эээ... аргумент в пользу чего? > Аббревиатура ACID, которой вы тут щеголяете, расшифровывается: Я уже как-то запутался, что именно Вы пытаетесь обосновать. Аббревиатуры ACID тоже нет в стандарте, кстати. ;) > Как видно, согласованность - отдельная от изоляции характеристика. Балее того, CAP-базы, которые Да, отдельная, и это правильно. Т.к. можно нарушать constistency, не нарушая isolation. Например, тупо игнорируя некоторые constraints (или игнорируя их в некоторых случаях). (Я слышал, что MySQL когда-то поступал именно так.) > обеспечивают согласованность (О, УЖАС!!!) без уровней изоляции. В CAP этот термин имеет совершенно другое значение, "О, УЖАС!!". :)

Аргумент в пользу того, что изоляция и согласованность друг друга не обуславливают. Это независимые характеристики БД. Они про разное. А вы пытаетесь их связать, причем через наивысший приоритет изоляции, что на мой взляд неправильно. Про стандарт и наличие в стандарте - это вы начали. Я в дядюшку Дейта тыкал изначально.

подскажите есть текстовое поле как из него поудалять тэги начинающиеся с #слово #слово2 ?

Аргумент в пользу того, что изоляция и согласованность друг друга не обуславливают. Это независимые характеристики БД. Они про разное. А вы пытаетесь их связать, причем через наивысший приоритет изоляции, что на мой взляд неправильно. Про стандарт и наличие в стандарте - это вы начали. Я в дядюшку Дейта тыкал изначально.

> Аргумент в пользу того, что изоляция и согласованность друг друга не обуславливают. Да, не обуславливают. Но все компоненты ACID перекрываются. К примеру, попробуйте представить не атомарную, но консистентную БД. Ну и так далее. Связь изоляции и консистентности состоит вот в этом: "The guarantee that any set of successfully committed concurrent Serializable transactions will have the same effect as if they were run one at a time means that if you can demonstrate that a single transaction, as written, will do the right thing when run by itself, you can have confidence that it will do the right thing in any mix of Serializable transactions, even without any information about what those other transactions might do, or it will not successfully commit." Т.е. в этом и есть большой практический смысл. Т.е. если программист обеспечил "correctness of the transaction in all ways the application programmer might have wanted", считая, что он в базе работает один... то, при использовании SERIALIZABLE, на этом его проблемы и закончились. > Я в дядюшку Дейта тыкал изначально. Это "определение" consistency далеко от хорошего (мягко говоря). Его можно прочитать так, что ему будут соответствовать совершенно неконсистентые вещи. :(

подскажите есть текстовое поле как из него поудалять тэги начинающиеся с #слово #слово2 ?

См. регулярные выражения. Т.е. оператор "~" и regexp_replace, скорее всего.

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

подскажите есть текстовое поле как из него поудалять тэги начинающиеся с #слово #слово2 ?

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

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

Эээ... никак не объясняю — они их, естественно, не видят. /С подозрением глядя на @dmitrykremer/ Вы точно представляете себе базовый (обычный) протокол обработки подобных исключительных ситуаций (implicit rollbacks) в СУБД? ;)

Эээ... никак не объясняю — они их, естественно, не видят. /С подозрением глядя на @dmitrykremer/ Вы точно представляете себе базовый (обычный) протокол обработки подобных исключительных ситуаций (implicit rollbacks) в СУБД? ;)

Вы сейчас про savepoint вы мне пытаетесь рассказать? Или про всякие мулечки в питоне и прочих?

протокол обработки подобных исключительных ситуаций .... Название у протокола-то есть? ))

Вы сейчас про savepoint вы мне пытаетесь рассказать? Или про всякие мулечки в питоне и прочих?

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

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

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

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

не бесконечно, а пока не получится

Ну если там очередь на 20 минут, то для пользователя это равно бесконечно