backupccl,kv: incorrect historical reads on RESTOREd tables

[dt]

Historical reads to before the SST was applied may be meaningless after SST application. For example, if RESTORE is used to RESTORE a table to 10:57, it is incorrect to allow a read (or backup) of that table to 10:56, or for a revision_history backup of that table at 10:59 to claim a revision_start_time of < 10:57.

I'm not quite sure what the fallout would be to forward gcthreshold to now on every ingest would be, since you could RESTORE a table to 1057 but that ingest might take an hour. Maybe the AddSST request should optionally carry the revision time to forward to?

Epic CRDB-8816

[dt]

this is an understood a limitation, and we'll be solidifying around RESTORE'd data appearing to have been written at the restoration time

[jseldess]

@dt, does your comment above mean that we should remove this known limitation? https://www.cockroachlabs.com/docs/v21.2/known-limitations.html#historical-reads-on-restored-objects

[dt]

Yeah, I suppose depending on how you define the term it isn't really a "known limitation" but just that's how RESTORE works. if you read as of before you restored the table, there's no table, so can't read anything -- is that a known limitation or just how it is? I dunno.

[jseldess]

@livlobo, can you chime in on whether we should remove this as a known limitation? https://www.cockroachlabs.com/docs/dev/known-limitations.html#historical-reads-on-restored-objects

[livlobo]

I agree with @dt . We can just describe it in the "restore" behavior rather than call it out as a "limitation".