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: 4277.1096060370@sss.pgh.pa.us (view raw or flat)
Thread:
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

Responses

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-2014 The PostgreSQL Global Development Group