SQL, transactions et isolation

From: Stephane Bortzmeyer <bortzmeyer(at)nic(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: SQL, transactions et isolation
Date: 2008-12-10 16:08:26
Message-ID: 20081210160826.GA14851@nic.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Je vais me permettre de poser une question qui ne concerne pas
réellement PostgreSQL. Car, avec PostgreSQL, tout marche bien mais je
voulais savoir ce qu'il en était d'autres SGBD.

La doc' de PostgreSQL prétend
<http://www.postgresql.org/docs/current/interactive/mvcc.html> et
l'expérience semble confirmer, que chaque transaction voit un
"snapshot" des données et que "reading never blocks writing and
writing never blocks reading".

Avec le niveau d'isolation par défaut, READ COMMITTED, une transaction
"de lecture" voit les commits des autres transactions (et ne peut donc
pas compter sur une vision cohérente des données).

Avec le niveau d'isolation SERIALIZABLE, par contre, une transaction
"de lecture" ne voit absolument pas les commits des autres
transactions (que ce soit pour des INSERT, des DELETE et des
UPDATE). Elle n'est pas bloquée pour autant, elle peut faire des
SELECT tant qu'elle veut et ils se terminent, rendant les données qui
existaient au début de la transaction (ce qui est bien le but des
transactions sérialisables). C'est parfait, c'est juste ce que je
voulais.

Mais ma question est :

Ce comportement de "snapshot" de PostgreSQL est-il imposé par la norme
SQL ? Pas sûr, on peut sans doute être compatible avec la norme en
mettant des simples verrous qui bloquent la transaction de lecture
tant que des écritures sont en cours. Si ce n'est pas standard, quel
SGBD a les mêmes capacités que PostgreSQL ? Tous ? Aucun ?

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Dimitri Fontaine 2008-12-10 16:36:33 Re: SQL, transactions et isolation
Previous Message Guillaume Lelarge 2008-12-10 12:57:33 Re: Fosdem 2009