Mike Matrigali wrote:
Andreas Korneliussen wrote:
Mike Matrigali wrote:
The SUR should not know anything about the underlying implementation
of the access method getting the row, so having it "read a timestamp"
from page does not work. If the timestamp is not in the rowlocation,
we could ad
Andreas Korneliussen wrote:
Mike Matrigali wrote:
The SUR should not know anything about the underlying implementation
of the access method getting the row, so having it "read a timestamp"
from page does not work. If the timestamp is not in the rowlocation,
we could add a get a timestamp for
Mike Matrigali wrote:
The SUR should not know anything about the underlying implementation
of the access method getting the row, so having it "read a timestamp"
from page does not work. If the timestamp is not in the rowlocation,
we could add a get a timestamp for row at this rowlocation, but for
Mike Matrigali wrote:
The SUR should not know anything about the underlying implementation
of the access method getting the row, so having it "read a timestamp"
from page does not work. If the timestamp is not in the rowlocation,
we could add a get a timestamp for row at this rowlocation, but for
The SUR should not know anything about the underlying implementation
of the access method getting the row, so having it "read a timestamp"
from page does not work. If the timestamp is not in the rowlocation,
we could add a get a timestamp for row at this rowlocation, but forcing
two trips to the s
I will modify the suggestion somewhat. I think first, that offline
compress is not a problem, even for the holdable SUR. Since offline
compress moves the records to another container, the SUR cursors should
detect that container they use is no longer valid, when renavigating
to the row.
If a
Some questions:
o row locations are stored in every index row. Are you proposing a data
level upgrade of every row in all databases?
o What is your proposal in the case of soft upgrade (note I believe not
supporting "holdable" SUR in soft upgrade is an option).
o The hard case is the compres
Following is a proposal to ensure that a client of store can verify the
validity of a RowLocation. A RowLocation has become invalid if a store
operation has caused it to point to another row or to a non-existent
position (deleted row or non-existing page/record-id).
I think we need a mechanis
