>> The point is this data inconsistency is >> lead by an inconsistent read but not by an inconsistent commit >> results. I think there are kinds of possibilities causing data >> inconsistency but atomic commit and atomic visibility eliminate >> different possibilities. We can eliminate all possibilities of data >> inconsistency only after we support 2PC and globally MVCC. > > IMO any permanent data inconsistency is a serious problem for users no > matter what the technical reasons are.
I have incorporated "Pangea" algorithm into Pgpool-II to implement the atomic visibility. In a test below I have two PostgreSQL servers (stock v12), server0 (port 11002) and server1 (port 11003). default_transaction_isolation was set to 'repeatable read' on both PostgreSQL, this is required by Pangea. Pgpool-II replicates write queries and send them to both server0 and server1. There are two tables "t1" (having only 1 integer column "i") and "log" (having only 1 integer c column "i"). I have run following script (inconsistency1.sql) via pgbench: BEGIN; UPDATE t1 SET i = i + 1; END; like: pgbench -n -c 1 -T 30 -f inconsistency1.sql In the moment I have run another session from pgbench concurrently: BEGIN; INSERT INTO log SELECT * FROM t1; END; pgbench -n -c 1 -T 30 -f inconsistency2.sql After finishing those two pgbench runs, I ran following COPY to see if contents of table "log" are identical in server0 and server1: psql -p 11002 -c "\copy log to '11002.txt'" psql -p 11003 -c "\copy log to '11003.txt'" cmp 11002.txt 11003.txt The new Pgpool-II incorporating Pangea showed that 11002.txt and 11003.txt are identical as expected. This indicates that the atomic visibility are kept. On the other hand Pgpool-II which does not implement Pangea showed differences in those files. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
