Warstone
А версионность нужна для того, чтоб когда один пишет - другие не видели что он написал.

Т.е. чтобы триггер не видел что уже написал вызвавший его DML.
Posted via ActualForum NNTP Server 1.4

Yo.!тут у нас транзакция видит изменения которая внесла, в тригере не видит
Опять ты зарапортовался и пропустил statement. DML это statement. Statement не видит
изменения которые внёс. И триггеру тоже их видеть ни к чему.

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

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

Версионность это всего лишь один из способов реализовать принцип "писатели не блокируют
читателей".
Posted via ActualForum NNTP Server 1.4

artemana
Вещь конечно сильно спецефическая, нужная только системам репликации, наверное.

Отдельным типам репликаторов - да. Но их мало. Собственно, из тех, которые не "только для
внутреннего употребления" мне таковые вообще неизвестны.
Posted via ActualForum NNTP Server 1.4

artemana
Про свой забыл? По моему ему и любым другим было бы 'приятно', если бы система могла
проверять fk и unique не для каждой операции, а при commit. Конфликтов было бы меньше.

Приятно - может быть. Но в штатном режиме мой репликатор как и любой другой, построенный
на логах не нарушает какие-либо констрейны. Отложенные констрейны нужны тем репликаторам,
которые работают без лога, на флагах или сравнении содержимого. Но как я уже сказал: если
кто-нибудь таковые на рынке знает - просветите. Мне не встречались.
Posted via ActualForum NNTP Server 1.4

artemana
А значит есть ситуации когда внутри транзакции констрайны нарушаются и ты с этим в штатном
режиме не справляешься. Сам же рассказывал.

Ну да, есть такая буква... Но, IMHO, оно не стоит того, чтобы вводить deferred
constraints. У них цена уж больно велика (если мне мой нюх не изменяет). Т.е. в простейших
случаях всё может быть и ништяк, но как я представлю транзакцию, внутри которой пара
миллионов DML и данные несколько раз проходят инвалидные состояния...

WarstoneТаким образом в Пг появится нативная master-slave репликация с hot stand.
Это отбрасывает необходимость "сторонних репликантов".
Щаззз... Оптимизм. WAL это просто отлично для простейшего standby в локалке.
Но в жизни кому ни попадя нужна неполная multimaster репликация, и вот тут-то WAL-а
становится недостаточно. Простейший случай: филиалы, в которых находится "урезанная" база,
обмениваются изменениями с центральной, причём часть данных, поступающих из филиалов
должна-таки не только попадать в центр, но и уходить в остальные филиалы.

Вон, у того же мускуля WAL уже давно есть, а мультимастер репликация ограничена ровно
двумя мастерами, причём один slave не может принимать изменения с двух мастеров одновременно.
Posted via ActualForum NNTP Server 1.4

WarstoneДа и его сложно сделать вообще-то.

На нативном уровне - сложно. На стороннем - как два пальца об асфальт. Всего-то две
проблемы решить:
1) Глобально-уникальные ключи
2) Предотвращение data bounce

Первое тривиально делается разнесением диапазонов у последовательностей или (не мелочась)
гуидами, а второе обычно магией пользовательских имён.
Posted via ActualForum NNTP Server 1.4