Setup:
* create database crashtest
* start 6 instances of testload.tcl as
./testload.tcl tN dbname=crashtest
where N = 1..6
* frequently kill a backend to cause a postmaster restart.The testload script creates a table and starts inserting rows, 2 to 6 per transaction. If the transaction succeeds, it increments the internal ID counter by the number of rows inserted. If the transaction fails with a dupkey error, it increments the ID counter by 1. On any failure, it reconnects to the database.
The duplicate key errors can happen because the transaction is committed, but the response doesn't reach the client before the crash. So that is a normal and expected behaviour.
But occasionally there will appear a gap in the data. With the given logic only to increment the counter on a dupkey or after a positive COMMIT response by the backend, IMHO there can only be one if we lose transactions after commit on a crash restart.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
lose_committed.tgz
Description: application/compressed
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
