This may not be what's happening, but there is a way to have committed
changes that make it to the serial log but not to the database. Some
months ago but after gophers proliferated, we realized that we were
As we all know, each gopher takes a transaction and applies all
Analysis showed that the problem was that Gopher A was working on
transaction 123 that did a lot of work, including (toward the end)
modifying record epsilon. Gopher B picked up Transaction 127
(started after 123 committed) which only made one change - to
record epsilon. Gopher B sometimes got to the change to record
epsilon before Gopher A. When that happened, Gopher B wrote
its change first, then Gopher A overwrote it with what should
have been an older version.
The solution was to have each Gopher check each record's list
of versions and not make changes on disk if the chain included
a newer (younger?) committed record. So, a record in the serial
log will never be written to a database pages if there is a
newer committed version.
Again - it's probably not the case you're looking at but it
did occur to me at about 2:30 this morning that it might be.
|• Records committed but not written||Ann W. Harrison||1 Nov|