Last week I announced the stable release of pg_chameleon as I felt quite confident the tool worked properly.
However the murphy law is always ready to teach us we live in an interesting universe. A couple of days after the release I noticed on a server which data were modified seldom a strange replica issue. For some reason at specific moments of the day the inserts replayed on the postgres tables failed with the primary key violation. It took me a while to reproduce the bug as this is an interesting corner case. This sequence of statemens on MySQL cause the replica break down on the version 1.0.
DROP TABLE IF EXISTS test; CREATE TABLE test( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, value1 VARCHAR(45) NOT NULL, PRIMARY KEY (id) )ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TEMPORARY TABLE tmp_test( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, value1 VARCHAR(45) NOT NULL, PRIMARY KEY (id) )ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into tmp_test (value1) values('blah'),('blah'); insert into test (value1) values('blah'); DROP TEMPORARY TABLE if exists tmp_test ;
This is caused by the batch not marked as closed when the query is received. The batch was closed only when the query were parsed. The statements CREATE TEMPORARY TABLE are not parsed (by design) and therefore the batch were not closed correctly. The subsequent row images generated by the inserts were read at each loop causing a replay issue because of the primary key violation.
I also took the occasion to complete the docstrings on the last library sql_util.py. Now the classes are is fully documented.
The release 1.1 is already available on pypi.
I’d really love to hear users’s stories.