WAL PVCs use default StorageClass during Postgres Operator upgrade from 3.0.0 to 4.2.4

Products

• VMware Tanzu Data Services Solutions
• VMware Tanzu for Postgres

Issue/Introduction

During an upgrade of Tanzu Postgres Operator from version 3.0.0 to 4.2.4, newly created WAL PersistentVolumeClaims (PVCs) may be provisioned using the Kubernetes cluster’s default StorageClass, even if the original Postgres instances were created using a different (non-default) StorageClass.

This behavior occurs during the automatic instance migration that is triggered after the operator upgrade which may result in:

• Pods getting stuck in Pending state
• Volume node affinity conflicts
• Scheduling failures
• Inconsistent storage placement

Pod describe output would show something like below:

Events:
  Type     Reason            Age                From                Message
  ----     ------            ----               ----                -------
  Warning  FailedScheduling  70s (x3 over 77s) default-scheduler   0/9 nodes are available: 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 6 node(s) had volume node affinity conflict. preemption: 0/9 nodes are available: 9 Preemption is not helpful for scheduling.

Cause

In Postgres Operator 4.x, the field walStorageClassName was introduced to allow explicit configuration of the WAL PVC StorageClass.

However, during migration from 3.0.0 to 4.2.4:

• The walStorageClassName field does not exist in 3.0.0 custom resources.

• The migration process cannot automatically determine which StorageClass was previously used for WAL volumes.

• As a result, the operator defaults to using the cluster’s default StorageClass when creating WAL PVCs.

This behavior is currently expected due to a migration limitations.

Resolution

Permanent Fix:

Postgres Operator which will be released by end of March 2026 (tentative ETA) is expected to provide the ability to explicitly define the WAL StorageClass during migration, eliminating the reliance on the cluster’s default StorageClass.

 

Workaround:

1. Temporarily set the intended StorageClass as Default.
2. Proceed with the upgrade from 3.0.0 to 4.2.4 and allow instance migration to complete.
3. After migration is successful, revert the cluster default StorageClass if required.