CockroachDB 21.1.4 preserves logs during inspection and bounds password work
Log inspection becomes an additional sink instead of taking over normal output. A separate semaphore prevents concurrent password checks from exhausting the server's CPU.
Inspecting a running database's logs should not prevent those logs from reaching their normal destinations. Before CockroachDB 21.1.4, using the logspy HTTP interface temporarily disabled output to files and network sinks. An operator looking for evidence could therefore create a gap in the durable record.
The June 29 release entry includes a correction to that behavior. Its logging patch explains the implementation change, replacing a singleton interceptor that took over output with an interceptor sink alongside the existing sinks.
I value operational visibility in a distributed database because a request can involve work on several nodes. That visibility has to remain dependable during an investigation. A diagnostic interface that suppresses the ordinary record changes the evidence while someone is trying to collect it.
Inspection becomes another destination
The old interceptor callback took control of the logger's output path. The patch description says entries stopped reaching files, standard error and network sinks while interception was active. It identifies the loss as a breach of auditability guarantees.
The replacement makes interception an ordinary sink on each logging channel. An active logspy session receives entries while the other configured destinations continue receiving theirs. That structure removes the reason inspection had to displace normal delivery.
The new sink also supports several concurrent interception sessions. Each receives the current entries, allowing different logspy requests to run beside one another. The patch gives different filtering patterns as an example of why several sessions can be useful.
This is a change in output routing, not a reconstruction of entries already lost during an earlier inspection. The fix preserves delivery during new sessions. An existing gap in a file remains a fact about the earlier logging history.
Verbosity becomes an explicit request
The routing correction creates a related concern. Previously, starting logspy automatically enabled maximum logging verbosity. Once normal sinks also receive those entries, automatic verbosity could impose unwanted disk and I/O work.
The patch therefore removes that automatic behavior. Logspy receives entries at the configured verbosity. An operator who needs more detail can request it with a vmodule parameter or the new debug/vmodule interface.
That separation lets inspection and verbosity be controlled independently. Reading the currently configured stream does not implicitly ask every verbose logging call to emit more data. Increasing verbosity remains possible, but it becomes a deliberate change.
The new interface can restore the previous verbosity configuration after a duration. Only one in-flight HTTP request can modify the setting, preserving the relationship between the saved configuration and the value restored afterward. A zero or negative duration requests no automatic restoration.
Output format also changes to JSON by default. The patch explains that escaped newlines keep an entry on one output line and make filtering more reliable. The older flat format remains available through the flatten parameter.
Those details affect existing diagnostic scripts. A parser expecting the old text needs an explicit compatibility option or a change to consume JSON. A script expecting automatic maximum verbosity also needs to request the desired setting.
Password checks share a bounded resource
A separate security patch addresses CPU starvation through password hashing. Rapidly opening and closing authenticated sessions in parallel could force the server to spend excessive CPU computing bcrypt hashes. The patch places a semaphore around those calls.
The limit applies across UI and SQL clients in the server process. It therefore constrains the expensive operation itself instead of relying on separate limits for each entry point. The implementation also uses the semaphore when generating password hashes.
Its default capacity is the configured GOMAXPROCS value divided by eight, with a minimum of one. The implementation computes that default when the semaphore is first used, giving server startup a chance to adjust GOMAXPROCS first.
An environment variable can override the capacity with a value of at least one. The variable is named COCKROACH_MAX_BCRYPT_CONCURRENCY. It controls concurrent hashing work, not the total number of database connections or a fixed number of login attempts per second.
I find that resource boundary appropriate because authentication consumes CPU before the session can perform useful SQL work. A faulty client and a malicious client can create similar pressure there. Limiting expensive checks protects the rest of the process without changing which password is accepted.
The fixes protect different operational obligations
The logging correction preserves the normal evidence stream while an operator inspects it. The authentication correction bounds a computationally expensive step shared by several client interfaces. Both address activity surrounding ordinary query execution that can otherwise interfere with the database process.
Neither change promises unlimited diagnostic traffic or cost-free authentication. Their mechanisms define narrower guarantees. Log inspection runs beside the other sinks, and bcrypt calls obtain capacity before doing their work. Those explicit boundaries explain what changes when this maintenance release is installed.