Found while working #4014.
What
PgLogEntryAssembler.s_prefixLine's space family is (?<zone>[^ \n]+) \[(?<pid>\d+)\]: the pid bracket must come right after the zone. Under a log_line_prefix that renders fields between them, for example '%m %u@%d [%p] ', which gives ... UTC app@db [5555] ERROR: ..., no line matches. It fails the space family, and the managed family needs a colon after the zone.
Every log family that reads through the assembler therefore stores nothing on such a target:
pg_log_events: every family is dropped.pg_deadlocks: both routes. PgDeadlockLogParser.FromReport goes through the assembler, and the deadlock patterns also demand the bracket after the zone.
Plan capture is the exception. Its own pattern accepts this shape since #4016 ([^ \[\n]+ [^\[\n]*\[\d+\]).
A test written for #4014, AReportUnderACustomPrefixWithFieldsBeforeThePid_StillReads, failed even with the deadlock pattern widened, because the assembler refused the candidate. It was taken out of #4014 rather than fixed there, for the reason below.
Impact
Unmeasured in the field. The common prefixes aren't affected:
- PostgreSQL's default
'%m [%p] ';
- pgBadger's
'%t [%p]: user=%u,db=%d,...';
- Cloud SQL's
'%m [%p]: [%l-1] db=%d,user=%u ';
- the managed default
'%t:%r:%u@%d:[%p]:'.
A target that does put fields before the pid reads as a server with no log events and no deadlocks, which is the silent-failure shape these families refuse by name elsewhere.
Fix
Extend the assembler's space family, both deadlock patterns and the log-events SQL to allow fields between the zone and the pid, as plan capture does, through a gap that excludes [. That keeps #4008's rule that the gap cannot pass the line's real bracket.
This is the reader #3996 hardened over several review rounds, and its label-boundary rules (s_prefixRun) must hold for the new run too. So it gets its own PR and a security review round, not a rider on #4014.
Found while working #4014.
What
PgLogEntryAssembler.s_prefixLine's space family is(?<zone>[^ \n]+) \[(?<pid>\d+)\]: the pid bracket must come right after the zone. Under alog_line_prefixthat renders fields between them, for example'%m %u@%d [%p] ', which gives... UTC app@db [5555] ERROR: ..., no line matches. It fails the space family, and the managed family needs a colon after the zone.Every log family that reads through the assembler therefore stores nothing on such a target:
pg_log_events: every family is dropped.pg_deadlocks: both routes.PgDeadlockLogParser.FromReportgoes through the assembler, and the deadlock patterns also demand the bracket after the zone.Plan capture is the exception. Its own pattern accepts this shape since #4016 (
[^ \[\n]+ [^\[\n]*\[\d+\]).A test written for #4014,
AReportUnderACustomPrefixWithFieldsBeforeThePid_StillReads, failed even with the deadlock pattern widened, because the assembler refused the candidate. It was taken out of #4014 rather than fixed there, for the reason below.Impact
Unmeasured in the field. The common prefixes aren't affected:
'%m [%p] ';'%t [%p]: user=%u,db=%d,...';'%m [%p]: [%l-1] db=%d,user=%u ';'%t:%r:%u@%d:[%p]:'.A target that does put fields before the pid reads as a server with no log events and no deadlocks, which is the silent-failure shape these families refuse by name elsewhere.
Fix
Extend the assembler's space family, both deadlock patterns and the log-events SQL to allow fields between the zone and the pid, as plan capture does, through a gap that excludes
[. That keeps #4008's rule that the gap cannot pass the line's real bracket.This is the reader #3996 hardened over several review rounds, and its label-boundary rules (
s_prefixRun) must hold for the new run too. So it gets its own PR and a security review round, not a rider on #4014.