Postgresql deadlocks

[Tomas Vondra]

On 5 Březen 2012, 10:02, Tomáš Krbec wrote:
> Dne 3. března 2012 1:17 Tomas Vondra <tv na fuzzy.cz> napsal(a):
>
>> On 2.3.2012 22:55, tomas.krbec na gmail.com wrote:
>> > Zdravím,
>> >
>> > ještě mne napadá, když vidím ten log. Říkáte, že se vyberou 2-3
>> záznamy
>> > a ty se potom updatují. Samozřejmě neznám ten kód, ale je nutné to v
>> > transakci updatovat řádek po řádku?
>> > Nedal by se použít jeden update?
>> > Něco jako:
>> >
>> > UPDATE "advert_advert" SET "views" =
>> > "advert_advert"."views" + 1 WHERE "advert_advert"."id" in (id1, id2,
>> id3)
>>
>> Ale to bude mít úplně stejný problém protože nedokážete zajistit v jakém
>> pořadí je databáze skutečně zamkne ... Bude se to lišit podle toho v
>> jakém pořadí je najde na disku (což se mění právě vlivem UPDATE).
>>
>> Pokud se chcete vyhnout deadlockům tak to skutečně musíte načíst a
>> updatovat pěkně jeden po druhém ...
>>
>> T.
>>
>
> Zde nesouhlasím. Databáze v tomhle případě ví, co má zamknout a zamkne
> všechny řádky anebo čeká.
> Když jsou ty updaty zapsané po jednom, tak v principu db nemůže ty řádky
> zamknout najednou a proto dojde k deadlocku, když do toho vleze další
> transakce

Nevím jestli máte na mysli "ideální databázi" nebo PostgreSQL (reálnou
databázi s reálnými implementačními omezeními), a nejsem si jist co
myslíte tím "ví co má zamknout". A není mi jasné zda popisujete aktuální
chování PostgreSQL, nebo jak by to podle vás mělo být.

Problém je v tom že databáze by buď musela provádět atomické uzamčení
všech těch řádků naráz (tj. nejdříve zkontrolovat že žádný není zamčený a
pak zamknout, a to vše tak aby to jiná session nemohla "narušit"). Nebo by
musela ty řádky někde nasyslit, setřídit a pak v daném pořadí zamknout.

Obě možnosti mají svá úskalí - omezení možnosti současného běhu více
sessions (při atomickém zamykání) nebo otázka podle čeho třídit/kde
ukládat při zamykání velkého počtu řádek k zamčení apod.

T.