On Aug3, 2010, at 00:43 , Florian Pflug wrote:
> Sounds good. That'll also give me some time to test the RI trigger
> infrastructure now that I've removed the crosscheck code.
Ok, I've found some time do run some additional tests.
I've created a small test suite to compare the behaviour of native (cascading) FK constraints to an PLPGSQL
implementation.There is a dedicated child table (native_child respectively plpgsql_child) for each of the two FK
implementation.Into both child rows for random parents are inserted, creating the parent if it does not already exists.
Concurrently,random parent rows are deleted.
The number of successful inserts into native_child respectively plpgsql_child and the number of successfull deletes are
counted,as well as the number of transactions failed due to either a serialization failure or a race condition during
theinsert (unique_violation or foreign_key_violation).
To verify that things behave as expected, the test suite reports a histogram of the number of parents over the child
countafter the test completes. The expected distribution is output alongside that histogram, assuming that the number
ofparents with N children follows an exponential distribution.
I've pushed the test suite togit@github.com:fgp/fk_concurrency.git
and put a summary of the results of my test runs onhttp://wiki.github.com/fgp/fk_concurrency/results.
The results look good. There is no significant change in the behaviour of FKs between HEAD and
HEAD+serializable_row_locks,and no significant difference between the native and plpgsql implementation. As expected,
theplpgsql implementation fails on an unpatched HEAD, aborting with the error "database inconsistent" pretty quickly.
I'd be interesting to run the plpgsql implementation with the SHARE locking removed against HEAD+true_serializability
tosee if that changes the number of serialization_failures that occur. I'll do that, but I'll have to wait a bit for
anotherspare time window to open.
best regards,
Florian Pflug