Jan Wieck <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
