Lightning.LogLines.SearchVectorWorker (Lightning v2.16.8-pre)

Backfills the full-text search_vector on log_lines rows.

Log lines are inserted with search_vector left NULL; the vector is built here rather than on the insert path, keeping to_tsvector off the hot path of high-volume log ingestion. Search is eventually consistent as a result, typically catching up within a minute.

Two database objects support this: safe_to_tsvector(regconfig, text), which builds the vector while tolerating NULL and oversized input, and a partial index over search_vector IS NULL, which keeps locating pending rows cheap as the table grows. Vectors use the english_nostop config to match the read side (Lightning.Invocation), which queries with to_tsquery('english_nostop', ...).

Each run drains pending rows newest-first, in batches up to a per-run budget (batch size and max batches are configurable via Lightning.Config). A run that exhausts its budget leaves backlog behind and enqueues an immediate follow-up ("snowball"); otherwise the minute-ly cron tick keeps pace. The worker runs on the dedicated search_indexing queue at concurrency 1, so only one job executes at a time, and the cron tick and the snowball carry distinct trigger args, so job uniqueness allows one of each to queue but never a duplicate.