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

Re: 7.4.5 losing committed transactions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.4.5 losing committed transactions
Date: 2004-09-24 21:12:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> 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.

Hmm.  I was able to reproduce this in 7.4.5 but not (so far) in 8.0.

What I see in the 7.4.5 postmortem is that the "missing" rows are
present in the table, as you'd expect, and are marked as inserted by a
transaction number that *definitely did not commit* according to the WAL
log --- there are WAL entries showing it inserting the missing rows,
and their btree index entries, but no commit.  The post-crash database
state seems exactly consistent with what is in WAL.

This means either that the server sent a commit message before it had
xlog'd the commit, or that Pgtcl mistakenly reported the command as
successful when it was not.  Any thoughts?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Jan WieckDate: 2004-09-24 22:17:35
Subject: Re: 7.4.5 losing committed transactions
Previous:From: Andrew DunstanDate: 2004-09-24 21:05:54
Subject: PG Build Farm Status

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