Zakleszczenia w PostgreSQL przy uruchamianiu UPDATE

Question

Jestem trochę zdezorientowany, czytając o zakleszczeniach PostgreSQL.

Typowym przykładem jest impas:

-- Transaction 1 
UPDATE customer SET ... WHERE id = 1 
UPDATE customer SET ... WHERE id = 2 

-- Transaction 2 
UPDATE customer SET ... WHERE id = 2 
UPDATE customer SET ... WHERE id = 1 

Ale co, jeśli mogę zmienić kod w następujący sposób:

-- Transaction 1 
UPDATE customer SET ... WHERE id IN (1, 2) 

-- Transaction 2 
UPDATE customer SET ... WHERE id IN (1, 2) 

Będzie możliwość zakleszczenia tutaj?

Zasadniczo moje pytanie brzmi: w drugim przypadku PostgreSQL blokuje wiersze jeden po drugim, lub blokuje cały zakres objęty warunkiem WHERE?

Z góry dziękuję!

Answer 1

W PostgreSQL wiersze zostaną zablokowane podczas ich aktualizacji - tak naprawdę to działa tak, że każda krotka (wersja wiersza) ma pole systemowe o nazwie xmin, które wskazuje, która transakcja spowodowała powstanie tej krotki (przez wstawienie lub aktualizację) i pole systemowe o nazwie xmax wskazujące, która transakcja wygasła, która jest krotka (przez aktualizację lub usunięcie). Po uzyskaniu dostępu do danych sprawdza każdą krotkę, aby określić, czy jest ona widoczna dla transakcji, sprawdzając aktywny "zrzut" w odniesieniu do tych wartości.

Jeśli wykonywana jest aktualizacja, a krotka odpowiadająca warunkom wyszukiwania ma wartość xmin, która będzie widoczna dla migawki i xmax aktywnej transakcji, blokuje ona oczekiwanie na zakończenie tej transakcji. Jeśli transakcja, która po raz pierwszy zaktualizowała krotkę, transakcja zostanie wznowiona i przetworzony zostanie wiersz; jeśli pierwsza transakcja zostanie zatwierdzona, twoja transakcja zostanie pobudzona i podejmie działania w zależności od poziomu izolacji obecnej transakcji.

Oczywiście, impas jest wynikiem tego, że dzieje się to w wierszach w innej kolejności. W pamięci RAM nie ma blokad na poziomie wiersza, którą można uzyskać dla wszystkich wierszy w tym samym czasie, ale jeśli wiersze są aktualizowane w tej samej kolejności, nie można mieć blokady kołowej. Niestety sugerowana składnia IN(1, 2) nie gwarantuje tego. Różne sesje mogą mieć różne czynniki kosztu aktywne, zadanie "analiza" tła może zmienić statystyki dla tabeli pomiędzy generowaniem jednego planu a drugim, lub może wykorzystywać seqscan i być zależne od optymalizacji PostgreSQL, która powoduje nowy seqscan dołączyć do już trwającego i "zapętlać się", aby zmniejszyć dyskowe operacje we/wy.

Jeśli wykonujesz aktualizacje pojedynczo w tej samej kolejności, w kodzie aplikacji lub przy użyciu kursora, będziesz miał tylko proste blokowanie, a nie zakleszczenia. Ogólnie rzecz biorąc, relacyjne bazy danych są podatne na awarie serializacji i najlepiej jest uzyskać do nich dostęp za pośrednictwem architektury, która rozpozna je na podstawie SQLSTATE i automatycznie ponawia całą transakcję od samego początku. W PostgreSQL błąd serializacji zawsze będzie miał wartość SQLSTATE 40001 lub 40P01.

http://www.postgresql.org/docs/current/interactive/mvcc-intro.html