Mike Matrigali wrote:
Andreas Korneliussen wrote:
Mike Matrigali wrote:
I was not aware of the alter table dependency check for offline
compress, this must be outside of store somehow - maybe something
tied to all alter table statements. It may make sense
to change online compress to hook up with whatever offline compress
is doing to make this happen.
Just testing the current system does not mean that future changes
won't break SUR. Unless we agree to change the contract on unlocked
RowLocations, then it still isn't right for code to depend on
an unlocked RowLocation not ever pointing to the wrong row - because
of the issue with truncate. Some possible issues with your test
in the online compress case:
I think you previously said:
"
In current access methods this could be enforced this while holding a
easily if the table level intent
lock requirement is added.
I would be comfortable adding this to store contract. It
seems reasonable and allows coordination through locking. "
I therefore think it would be good if the contract said:
* truncate and compress requires exclusive table locking
* the truncate, purge and compress operations do not share any locks
with user transactions
This seems fine, but may require changes to store code and inplace
compress to actually support such a contract in store. The previous
changes just documented what was already supported.
Note: I am here discussing the non-holdable case only.
Yes, I guess you are thinking of the part with not sharing any locks
with user transactions? This comes from the problem of a user running
online compress from the same connection as the SUR.
Truncate should be changed to run in a separate transaction, in order
for the store to be consistent with the proposed contract.
A minimal requirement from SUR is that defragment does not share any
locks with the user transaction. If the rows cannot be defragmented,
then none of the pages which we have read RowLocation from can be
truncated. Defragment currently is in line with what we need, since it
runs in a separate transaction.
Purge would only affect committed deleted rows (I guess no user
transaction could lock these ?).
I still don't see how this helps the holdable case, I agree this helps
the non-holdable case.
Yes, I know this only helps the non-holdable case.
Andreas
