Skip site navigation (1) Skip section navigation (2)

7.4.5 losing committed transactions

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: 7.4.5 losing committed transactions
Date: 2004-09-24 20:10:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
The attached archive contains a script that I used to reproduce the 
error multiple times.


   * 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.


# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

Attachment: lose_committed.tgz
Description: application/x-compressed (1000 bytes)


pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2004-09-24 20:26:09
Subject: Re: SQL-Invoked Procedures for 8.1
Previous:From: Cott LangDate: 2004-09-24 19:20:50

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group