test(linux): give a server-paged last page twice the export's time

linux/crates/test-support/src/conformance/cases/large_table.rs

@@ -64,6 +64,10 @@ const SAMPLE_PAGES: usize = 100;
 const DEPTH_FACTOR: u32 = 4;
 const DEPTH_SLACK: Duration = Duration::from_millis(10);
 
+/// Skipping to the last page reads every row at the server's speed, as
+/// the export does, so on ScyllaDB the two take about as long.
+const SKIP_FACTOR: u32 = 2;
+
 /// A 1,000,000-row table pages from its first page to its end, by the
 /// browse tab's default page size and the way its pager moves on, and
 /// its last page reads straight from the end. An export of the whole
@@ -197,7 +201,7 @@ fn check_bounds(measured: &Measured) -> Result<(), ConformanceFailure> {
     // Where the server pages, the last page is reached only by reading
     // every row before it, as the export reads them all.
     let last_limit = match measured.mode {
-        PagingMode::ServerPaging => PAGE_LIMIT.max(exported.elapsed),
+        PagingMode::ServerPaging => PAGE_LIMIT.max(exported.elapsed * SKIP_FACTOR),
         PagingMode::Keyset | PagingMode::CtidWindow | PagingMode::Offset => PAGE_LIMIT,
     };
     expect(CASE, *last <= last_limit, || {

linux/docs/testing.md

@@ -182,7 +182,7 @@ The PostgreSQL, MySQL, SQL Server, ClickHouse, SQLite and DuckDB targets run it,
 
 - It counts the table, then pages from the first page to the end by the browse tab's default page size, each page read past the edge row's key, by offset where the engine pages that way, or resumed from the server's paging state, as `BrowsePager` moves on. The last page is then read from the end, or by offset where the server pages. Every row is checked, in id order or, where the server pages a scan in its own order, once each.
 - It exports the table through the statement `build_export` writes, streamed by `stream_read` with no deadline into a CSV file in 64 KiB chunks, as the export dialog's Entire Table does. Every line of the file is checked.
-- The walk, each page and the export have time bounds, and where pages seek, the last pages may not take much longer than the first. Where the server pages, the last page is reached only by reading every row before it, so it may take as long as the export, which reads them all. Neither the walk nor the export may raise the process's resident peak (`VmHWM`, reset through `/proc/self/clear_refs`) past a memory bound. The bounds are constants in `crates/test-support/src/conformance/cases/large_table.rs`.
+- The walk, each page and the export have time bounds, and where pages seek, the last pages may not take much longer than the first. Where the server pages, the last page is reached only by reading every row before it, so it may take up to twice as long as the export, which reads them all at the same speed. Neither the walk nor the export may raise the process's resident peak (`VmHWM`, reset through `/proc/self/clear_refs`) past a memory bound. The bounds are constants in `crates/test-support/src/conformance/cases/large_table.rs`.
 
 The peak is the whole process's, so the case needs a process to itself. The PostgreSQL, MySQL, MariaDB, SQL Server, ClickHouse, Cassandra and ScyllaDB targets pass `docker: true` and run under cargo-nextest, which gives each test a process of its own. The `ci` nextest profile prints its times and memory for a passing run, so the job log keeps what the bounds are set from.