sql: lower defaults for sql.guardrails.max_row_size_log and sql.guardrails.max_row_size_err

[michae2]

The defaults of sql.guardrails.max_row_size_log and sql.guardrails.max_row_size_err are 64 MiB and 512 MiB, respectively, and have been since they were added in #67953. These default values were purposefully very conservative. What we've found, however, is that large rows tend to run into kv.raft.command.max_size first, which is confusing.

We should lower the defaults for sql.guardrails.max_row_size_log and sql.guardrails.max_row_size_err so that they come into effect before kv.raft.command.max_size.

Jira issue: CRDB-58626

[michae2]

See this slack conversation for example.

[michae2]

We might want to also do #137518 if we're in the neighborhood.

[dt]

While separate column families can help circumvent raft command size limits, some features that traffic in SQL rows do require handling entire rows at once. One example here is BACKUP, which has a 64mb response size target when reading from KV that can be exceeded by at most 16mb, meaning if the last row it reads is >16mb, or indeed if any single row is greater than 64+16mb, it cannot be backed up. There a similar limit in IMPORT where the maximum size of a single value is also 64mb. There are probably other places that misbehave with giant rows as well given this is not a configuration that has robust test coverage.

[michae2]

Hmm. To be clear, sql.guardrails.max_row_size_log and sql.guardrails.max_row_size_err currently apply to individual column families. Are you thinking they should apply to the entire row?

[michae2]

[issue triage] considering this for 26.2