В PostgreSQL реализована модель когда читающие транзакции не блокируют пишущие.
Как организовать в таком случае блокировку от чтения определенного набора строк в таблице, на то время пока другая транзакция их прочитала и пишет в таблицу? Или я просто не совсем понял смысл работы "версионного механизма".

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

Maxim BogukТимошенко АлександрДля примера система складского партионного учета, надо выбрать данные о остатках, потом сформировать записи "расхода", проставив в них партии по фифо из остатков, потом записать их. Другие транзакции таблицу(не всю конечно, а по данному складу и данной номенклатуре) пока все это происходить читать не должны.

Хоть убейте не понял почему "Другие транзакции таблицу(не всю конечно, а по данному складу и данной номенклатуре) пока все это происходить читать не должны"?
Пока вы транзакцию не commit никто этих изменений не увидит ни при каких условиях.

--
Maxim Boguk
www.postgresql-consulting.ru

Ну как. у вас на складе 10 шт товара А (5 партий во остатке)
А пр1 - 2 шт
А пр2 - 2 шт
А пр3 - 2 шт
А пр4 - 2 шт
А пр5 - 2 шт


2 транзакции хотят списать данные, скажем каждая хочес писать по 2 шт товара А

1. тр1 Читает данные об остатках - видит картину выше списывает 2 шт из пр1
2. тр2 Читает данные об остатках - видит картину выше списывает 2 шт из пр1
3. тр1 записывает в таблицу расход, и меняет остатки
4. тр2 записывает в таблицу расход, и меняет остатки


В итоге у нас минус по первой партии

vyegorovТимошенко Александр,

А почему вы думаете, что "меняет остатки" должно что-то изменить в таблице, а "списывает" не должно?
Если вы сделаете всё в рамках транзакций, то у вас возникнет конфликт писателей, и всё будет правильно.

Немного не точно выразился, запись в таблицу(списание), это и есть "меняет остатки"

Грубо говоря будет так
тр1 SELECT
тр2 SELECT
тр2
тр2 SELECT

Тимошенко АлександрvyegorovТимошенко Александр,

А почему вы думаете, что "меняет остатки" должно что-то изменить в таблице, а "списывает" не должно?
Если вы сделаете всё в рамках транзакций, то у вас возникнет конфликт писателей, и всё будет правильно.

Немного не точно выразился, запись в таблицу(списание), это и есть "меняет остатки"

Грубо говоря будет так
тр1 SELECT
тр2 SELECT
тр2
тр2 SELECT

Грубо говоря будет так
тр1 SELECT
тр2 SELECT
тр2 INSERT
тр2 INSERT


Проблема в том что первые два селекта считают одинаковые состояния таблицы

IgorNKЗаписываете транзакцией. В момент записи делаете проверку. Если не хватает, откатываете все назад, обновляете данные клиенту и говорите ему: "Ты не успел, Вася. Петя был шустрее."
Да, партия 1 уже списана, и тогда вася спросит, ведь есть же еще партия 2 и при чем тут петя? Партии то подбирает алгоритм.

qwwqТимошенко АлександрДля примера система складского партионного учета, надо выбрать данные о остатках, потом сформировать записи "расхода", проставив в них партии по фифо из остатков, потом записать их. Другие транзакции таблицу(не всю конечно, а по данному складу и данной номенклатуре) пока все это происходить читать не должны.рассуждение про сферические транзакции в вакууме. на сферически организованной структуре.
любителям сферических блокировок есть transaction isolation lavel serializable (надеюсь не описался -- не держу в памяти за ненадобностью).

для разведения проблемы при рид коммитеде -- делаете изменение остатков инкрементально, наваривая только что тут же (в том же стейтменте) прочитанный остаток. второй пришедший к записи встанет на неё в очередь. и запишет свой инкремент только на закомиченное значение.

если же логика сложна и развесиста -- т.е .читаете вы в одном месте, потом долго считаете, потом навариваете, уже сильно забыв, что читали -- то есть select for update -- для организации очереди потенциальных писателей в момент первого прочтения. и unique -- для организации очереди на insert. ...и т.п. и т.д. например т.к. insert no wait нет -- там, при необходимости делается адвайзори лок.... т.е. мыслите в терминах подхода к снаряду. разделяемому сиречь ресурсу -- и всё наладится.

select for update наверное то что надо. Но вопрос в пространств которое он заблокирует, всю таблицу или только записи попавшие в выборку?

qwwqТимошенко Александрпропущено...

Да, партия 1 уже списана, и тогда вася спросит, ведь есть же еще партия 2 и при чем тут петя? Партии то подбирает алгоритм.ну вот, вы сами определились -- нужна очередь в подходах к фифу. т.е. записям партионного учета.
вот и говорите "селект форе апдейт" в момент подхода к ним и пети и васи. пришел вася -- встал в очередь, потому, что петя не отпустил еще коммитом или ролбаком.
отпустит -- тут их вася и прочитает "для апдейту". и надругается разно.

Вопрос еще с пространством блокировки
если петя списывает товар А
а вася товар Б

то они не должны друг друга блокировать, SELECT FOR UPDATE справиться с этим?

Maxim BogukТимошенко Александрпропущено...


Вопрос еще с пространством блокировки
если петя списывает товар А
а вася товар Б

то они не должны друг друга блокировать, SELECT FOR UPDATE справиться с этим?

справится при аккуратном применении (не лочить то что не надо).

--
Maxim Boguk
www.postgresql-consulting.ru

Ок, спасибо

qwwqТимошенко Александр,

вас на 4 буквы послать ?

посылаю RTFM
оттуда сами можете все раскопать, например вот это ещё rtfm

и потихоньку, кирпичик за кирпичиком -- жызнь и наладиццо

Ну раз уж послали, тогда ок, спасибо отзывается:)