Рабочие будни

[beldmit]

Я уж думал, этот баг в PostgreSQL давно пофиксили - таблица с уникальным ключом по дате, делаем апдейт, увеличивая дату на день - получаем нарушение уникальности. Во времена коммунивера я на такое тоже натыкался, как сейчас припоминаю. Если дату уменьшать, а не увеличивать - все нормально.

Еще один сюрприз - то, что в PostgreSQL нет dirty read. Как следствие триггер BEFORE INSERT, обеспечивающий отсутствие пересечения диапазонов, можно обмануть и вставить из разных транзакций диапазоны, которые все-таки пересекутся. Предыдущий автор кода от этого застраховался LOCK TABLE. Что естественно, не фонтан.


Но это все фигня. Через неделю надеюсь похвастаться результатом, имеющим публичное значение.

Comments

[sunders.livejournal.com]

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

[shutofsky.livejournal.com]

Ой, (BEEP). А нельзя мигрироваться в нормальную коммерческую СУБД? Посмотри внимательно, как выглядит лицензия на пробную DB/2, к примеру, может есть какая лазейка. Да, она не поддерживает мультипроцессорность. Но ИМХО по функционалу и производительности оный постгрес как бык овцу перекроет...

[vitus_wagner]

Нормальных коммерческих СУБД не бывает. У всех лидеров рынка (Oracle, DB2 etc) внутри разложены точно такие же грабли как у Postgres и в сравнимом количестве. Просто у Postgres их можно, если очень приспичило, влезть и поправить, а у Oracle/DB2 - нет.

Ну, насчет влезть и поправить

[cmike.livejournal.com]

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

А вот про Оракл попрошу подробнее.

[shutofsky.livejournal.com]

Дык разложено. Но все-таки не таких :).

[beldmit.livejournal.com]

Обсуждалось в свое время, еще до меня. Но в общем - не нужно. В смысле, не настолько нужно, потому как и этот апдейт нужен очень редко, и без DIRTY READ обойтись можно - достаточно правильно продумать архитектуру.

[shutofsky.livejournal.com]

А. Нет, понятно что можно продумать. И в общем-то и коммерческую СУБД всерьез можно раскорячить кривым SQL. Но странно оно как-то.

[ex-croco667.livejournal.com]

Бррр, а напомни, что за зверь dirty read? а то ни фига не помню уже теорию

[beldmit.livejournal.com]

Он же read uncommited. Данные, внесенные другой транзакцией.

[sdols.livejournal.com]

Недавно интересовался, на чем работают современные веб-онлайн-игры. Прям радость берёт - в лучшем случае Postgre. Как правило - вообще MySQL. И это при том, что в деле пропаганды опенсорса есть еще непокорённые вершины!

[beldmit.livejournal.com]

Так это. У нас система здоровая - и возможностей PostgreSQL вполне хватает. Там, где не хватает - надо переделать, там проблема архитектурная. А если бесплатных возможностей хватает - зачем платить?

[sdols.livejournal.com]

Ну дело-то не в ценах. И именно в том дело, что дело не в ценах :) Народ выбирает для решения задач софт не по соображениям общей эффективности, а по соображениям стоимости пакета. В результате некоторые задачи, для которых к примеру MS SQL - самое ОНО, выполняются на заведомо проигрышных платформах. Твой случай в рассчет не беру т.к. убеждён, что учитывались иные критерии.

http://npj.ru/arioch

[arioch [npj.ru] (from livejournal.com)]

ЕМНИП, Postgres - версионник ? Как ты в версионнике сделаешь dirty read ? Не все режимы блокировочников можно перевести на версионники и наоборот. В Firebird то же самое должно быть.

А через Check constraint это нельзя слелать ? Туда нельзя вложить select ? Хотя это м.б. еще тяжелее блокировки будет.

...или промежуточный слой сделать :-)

[arioch [npj.ru] (from livejournal.com)]

sorry за ссылку.
not intentional.

Промахнулся и вбил ее вместо имени в тему :-(

[beldmit.livejournal.com]

Так. Наблюдаю отсылки к какой-то теории, которую я не знаю, но знать должен. Можно
подробностей?