SELECT version();
version
------------------------------------------------------------------------------------------
PostgreSQL 9.6.0 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
(1 ligne)
CREATE TABLE t1(c1 INTEGER);
CREATE TABLE
INSERT INTO t1(c1) VALUES(1);
INSERT 0 1
COMMIT;
COMMIT
-- Dans toutes les sessions AUTOCOMMIT à off
-- SESSION 1
START TRANSACTION;
START TRANSACTION
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET
-- un 1er select pour démarrer effectivement la transaction, en principe nous devons avoir la vision de la base telle quelle éait à ce timestamp
SELECT CURRENT_TIMESTAMP;
now
-------------------------------
2016-10-23 17:21:05.277637+02
(1 ligne)
-- SESSION 2
TRUNCATE TABLE t1;
TRUNCATE TABLE
COMMIT;
COMMIT
-- SESSION 1
SELECT * FROM t1;
c1
----
(0 ligne)
-- SESSION 0
INSERT INTO t1(c1) VALUES(1);
INSERT 0 1
COMMIT;
COMMIT
-- SESSION 1
START TRANSACTION;
START TRANSACTION
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET
-- un 1er select pour démarrer effectivement la transaction, en principe nous devons avoir la vision de la base telle quelle éait à ce timestamp
SELECT CURRENT_TIMESTAMP;
now
-------------------------------
2016-10-23 17:40:52.183946+02
(1 ligne)
-- SESSION 2
DELETE FROM t1;
DELETE 1
COMMIT;
COMMIT
-- SESSION 1
SELECT * FROM t1;
c1
----
1
(1 ligne)
-- SESSION 2
TRUNCATE TABLE t1;
-- en attente puisque la session 1 a accédé à t1 !
OK normalement le 1er "SELECT * FROM t1" aurait dû voir la ligne supprimée par le TRUNCATE de lautre session. Si vous effectuez le test avec un DELETE au lieu du TRUNCATE cest le cas. Mais cest vraiment un problème très mineur. Dans 99,999..% des utilisations, TRUNCATE ne pose aucun problème dans le respect des niveaux disolation sous PostgreSQL.