Блокировки на уровне записей Postgresql #499442

Почитал описание постгрей. Оказывается сам постгрей умеет делать любые блокировки, хоть на уровне таблиц, хоть на уровне записей. А кроме того умеет как то хранить историю элементов, чтоб совсем без блокировок. Многоверсионный контроль конкурентых транзакций и изоляция транзакций -------------------------------------------------------------------------------- В PostgreSQL реализован (Multiversion Concurrency Control, MVCC) - многоверсионный контроль конкурентных транзакций, который управляет конкурентным доступом к данным на многоверсионной основе. На практике это означает, что при запросе к БД каждая транзакция видит как бы снимок данных (версию) на момент этого снимка, а не текущее состояние данных. Таким образом транзакции защищаются от просмотра нецелостных данных, которые могут ещё только формироваться другими конкурентными транзакциями в тех же самых строках таблицы. Этим же достигается изоляция транзакций для каждой сессии к БД. MMVC позволяет избегать методов явной блокировки, которые применяются в традиционных СУБД и таким образом, минимизирует блокировки данных и позволяет увеличить производительность в многопользовательской работе. Основное преимущество MMVC состоит в том, что чтение данных никогда не блокирует запись, а запись никогда не блокирует чтение. Также в PostgreSQL реализованы традиционные схемы явных блокировок данных, применяющихся для изоляции транзаций, такие как: блокировка на уровне таблицы блокировка на уровне записи в таблице (строки) advisory блокировки (для собственных блокировок на уровне приложений) Также реализовано отслеживание deadlocks (взаимных блокировок) Соответственно вопрос. 1С не постаралась реализовать полную работу с постгреем?

Так я не понял, 1С работает с постгри на уровне записей или нет?

1с работает с блокировками в постгрей на уровне таблиц

+

управляемые блокировки - на уровне записей

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

не осилили

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

Row-level locks do not affect data querying; they block writers to the same row only. Уровень изоляции SERIALIZABLEREPEATABLE READ не получится с блокировками на уровне записей.

а как нибудь на русский перевести можно )

Блокировки строк не затрагивают запросы к данным; они блокируют только запись в тех же строках. Т.е. те данные которые вы сейчас читаете могут кем-то изменяться в этот же момент времени.

Странный вывод.

можете пояснить?

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

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

Ну я имел в виду несколько иное, наверное. При такой схеме, когда "писатели" не блокируют "читателей" могут возникать фантомы и, возможно, проявляться неповторяемое чтение - собственно именно это я хотел сказать. Идея о блокировании чтения, при изменении данных, собственно из требования к отсутствию фантомов в serializable и неповторямого чтения в repeatable read. Если мы в одной транзакции дважды обращаемся к одним и тем же данным, но в "перерыве" между обращениями кто-то изменил эти данные мы ведь, при повторном чтении, получим те же самые версии строк, которые были на начало транзакции, правильно? Это, конечно, очень даже повторяемое чтение, но какое-то неправильное, имхо. Или я где-то ошибаюсь?

я так понимаю это один из возможных вариантов работы блокировок. читай до конца. тебя же на mvcc (достижении) постгрея заклинило.

зачем продвигать бесплатный софт?

Понятно, что не меняя запросы реализовать автоблокировки такие же как при работе в MS SQL вряд ли получится. Тем не менее наверное можно использовать SELECT FOR UPDATE чтобы попытаться заблокировать данные от изменения другими транзакциями. Никаких принципиальных барьеров к реализации автоблокировок в понимании 1С на уровне записей у движка постгре нет. Надо только чуть-чуть доработать его напильником, что сделать поленились по ряду причин. Зато например проблема эскалации блокировок для постгре и оракла не актуальна, что является несомненным плюсом.

Можно, но меня смущает, например это: "However, locking a row may cause a disk write; thus, for example, SELECT FOR UPDATE will modify selected rows to mark them locked, and so will result in disk writes." Т.е. при такой блокировке заблокированные строки должны быть помечены как "заблокированные" и запись об этом должна быть на диске? Польза от отсутствия эскалации блокировок - это довольно спорный вопрос.. Я вижу в ней как плюсы, так и минусы. Я правильно понимаю, что вы работаете с PostgreSQL? При использовании SELECT FOR UPDATE мы можем получить фантомы? А вообще, существуют ведь тысячи приложений, нормально работающие с версионниками - конечно 1С могла бы "допилить" свой механизм, но это наверняка не "чуть-чуть допилить".

1. Да, оракл тоже пишет биты блокировок непосредственно в данные, правда там они не всегда сразу попадают на диск. Это очень экономит ресурсы по сравнению с моделью мс скуля, где блокировки каждого сеанса хранятся в памяти. Эскалация - это просто костыль для экономии памяти под блокировки, что не актуально для оракла и постгри. 2. Непосредственно с постгри не работаю, но имею опыт с ораклом, где всё несколько сложнее, но похоже на постгри (возможно в силу заимствований некоторых идей разработчиками последнего). При SELECT FOR UPDATE, если верить документации по ссылке из возможно вставить строку, которая должна бы изменить результат запроса при повторном выполнении - это пожалуй фича, которую нужно учитывать разработчику приложений. 3. Насчет "чуть-чуть" наверное погорячился, хотя отличий и так немало, не только в механизме транзакций и блокировок, однако же смогли выпустить мультиплатформенную версию.

1. Ну знаете, я все же предпочту хранить блокировки в памяти, чем генерировать тысячи i/o-операций при блокировке какой-нибудь таблицы и, имхо, вот здесь как раз эскалация очень бы помогла - поставил "галочку" что таблица заблокирована и работай дальше, не трать время на чтениезапись каждой строки. Эскалация на пустом месте не возникает (если не считать какие-то очень маленькие таблицы, влезающие в пару страниц данных - тут действительно может быть проблема), а является нефиговым таким "звоночком", что что-то работает неправильно. Если вы считаете, что эскалация "ошибочна", SQL Server 2005 позволяет ее отключить на уровне сервера, а SQL Server 2008 и на уровне таблиц. 2. Хе, ну если чтение "фантомов" на уровне изоляции serializable - это "фича", пусть будет так. С repeatable read, в принципе, согласен - SELECT FOR UPDATE и SELECT FOR SHARE помогут. 3. Смогли, но я так понимаю, что только за счет того, что postgresql (и, наверное, oracle, но тут я не в курсе) позволяет работать с собой как с блокировочником, но с некоторыми "особенностями". И чтобы последствий от таких "фич" избежать и используют блокировку на уровне таблиц - чтоб уж наверняка никаких проблем (:.