Re: 7.4.5 losing committed transactions

Jan Wieck <JanWieck@Yahoo.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