postgres a lockovanie

[mIHAU]

>Napriklad cinnost nasledujiciho typu je typicka beztransakcni ;-)
>
>insert into objednavky (select from kosik where zakaznik=1);
>delete from kosik where zakaznik=1;
>update zakaznici set zakaznik=zakaznik+1;
>
>Kdyz vam chcipne nasledny delete a update a MySQL vam objednavku
>nezrusi a neda zakaznikovi 1 vedet, ubohy zakaznik cislo jedna se
>smichy neudrzi, az mu prijde hromada neobjednaneho zbozi.

Tak nejak je ten kod nahore postaveny aby delal problem, ne? :)
Krome toho uvaha typu 'kdyz vam chcipne' mi pripada jako bezpredmetna, pokud to
chcipe na sql tak to muzete stejne zabalit... Ono totiz pri velkem loadu se
postgres stejne polozi takovym zpusobem, ze nejake transakce jsou sice hezke,
ale muzete klidne hledat backup databazi, protoze ty skonci v prakticky
neopravitelnem stavu (alespon pro bezneho uzivatele, ktery nechce studovat
interni format dat pg). Osobne zustavam verny postgresu ze zcela jinych duvodu
nez jsou transakce (ty mne spis s*****, hlavne nemoznost specifikovat alespon na
vybrane tables jiny storage manager nez ten no-overwrite).  Porad se myslim
bavime o webu, - spojeni na backend trva jen po dobu generovani stranky.

Zkuste taky pg delat select like ze 150000 zaznamu a pak to zkuste s mysql :)
--
Michal Samek, Tony distribuce s.r.o.
webmaster na tony.cz  (++420659/321350)
ICQ: 38607210