perf(woodpecker): set wal.maxParallel=2 on wp-pg-store (REN-165)

The barman-cloud plugin archives WAL serially when spec.configuration.wal.maxParallel is unset — the v0.15.0 CRD states "If not specified, WAL files will be processed one at a time". It is unset on every ObjectStore in this cluster, which is the ~14 segment/min drain ceiling measured on ha-pg over seven nights (REN-129). ha-pg's recorder purge fills pg_wal at 18.7–39.7 seg/min, so the serial archiver cannot keep up and the nightly backlog accumulates. wp-pg carries the change first. It is a real archiver on the same plugin and the same Hetzner bucket but it is CI infrastructure, so it is the safe place to answer the one open question: does editing an ObjectStore in place roll the CNPG instance pods? No ObjectStore in this repo has ever been edited in place, so there is no precedent. ha-pg is the live Home Assistant recorder and is not the place to find out. Same staged-rollout pattern used to verify archive_timeout on gf-pg before applying it to ha-pg. Revert: delete the maxParallel line and its comment. The field is additive — removing it restores serial archiving. Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 08:02:12 +00:00
1 changed files with 8 additions and 0 deletions
@@ -61,6 +61,14 @@ spec:
        key: REGION
    wal:
      compression: gzip
+      # Archiver concurrency. Unset means one WAL file at a time, which caps the
+      # drain rate at ~14 segments/min and is what lets ha-pg's nightly backlog
+      # accumulate (REN-165). wp-pg has no backlog of its own; it carries the
+      # change first because it is CI infrastructure on the same plugin and
+      # bucket, so it is the safe place to learn whether editing an ObjectStore
+      # in place rolls the CNPG instance pods -- the same staged rollout used to
+      # verify archive_timeout on gf-pg before ha-pg.
+      maxParallel: 2
    data:
      compression: gzip
  retentionPolicy: "30d"