percona / percona/percona-postgresql-operator

Support a dedicated PVC for logs (separate from pgData)

Open
#1,678 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature-request jira-task PG Proposed
Dominant language
Go
Stars
385
Forks
83
Avg merge
2d 5h
Merged PRs (30d)
39

Description

Proposal

K8SPG-851 (and the shared tech design in K8SPXC-485 / K8SPSMDB-297) adds persistent logging so logs survive a Pod restart, but in the current implementation logs are written to the same PVC as the instance data (e.g. pgBackRest logs to the pgData volume). There's no option to give logs their own PVC.

Add an optional dedicated logs volume claim spec, following the same pattern already used for WAL
a new LogVolumeClaimSpec that, when set, mounts a separate PVC for Patroni/Postgres/pgBackRest logs instead of writing them to pgData. When unset, behavior is unchanged.

Use-Case
  1. As a user, I don't want runaway log growth to risk filling my Postgres data volume and causing an outage.
  2. As a user, I want to choose a cheaper/different storage class for logs than for my Postgres data.
  3. As a user, I want log volume size to scale independently of data volume size.
Is this a feature you are interested in implementing yourself?

Yes

Anything else?

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the existing WAL volume-claim specification and its PVC and mount wiring. Compare how Patroni, Postgres, and pgBackRest logs currently use pgData, then define the done state as an optional LogVolumeClaimSpec that mounts a separate logs PVC while preserving current behavior when it is unset.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes, postgresql
Domain
database, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.