The attached archive contains a script that I used to reproduce the
error multiple times.
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. #
#================================================== JanWieck@Yahoo.com #
