Operator skips cluster update when changing controller ID

• Which image of the operator are you using? ghcr.io/zalando/postgres-operator:v2.0.1
• Where do you run it? Azure Kubernetes Service
• Are you running Postgres Operator in production? yes
• Type of issue? Bug report

Hello,

I'm currently experimenting with running two instances of Postgres Operator. After changing a cluster's controller ID, I've noticed that the Postgres Operator does not update the cluster immediately.

Description

When changing the acid.zalan.do/controller annotation on a Postgres cluster manifest, the corresponding Postgres Operator should update the cluster accordingly. However, the update is skipped and the cluster is updated during the next resync.

Reason

The postgresqlUpdate method checks both the previous and the current manifests using postgresqlCheck.

https://github.com/zalando/postgres-operator/blob/a7aaad0a0b9517bb46077f2925eb80ae8ebe1a0c/pkg/controller/postgresql.go#L526-L529

As the previous manifest's annotation doesn't match the operator's controller ID, the check fails and the update is skipped.

https://github.com/zalando/postgres-operator/blob/a7aaad0a0b9517bb46077f2925eb80ae8ebe1a0c/pkg/controller/postgresql.go#L559-L567

Suggested fix

I think the postgresqlCheck method should ignore ownership when checking the previous manifest.

I think postgresqlUpdate should enqueue an EventSync when the previous manifest's check fails (we cannot use EventUpdate here because the K8s objects may or may have been created by the other Postgres Operator, which may or may not exist).

Note: I realize we may run into a race condition because we don't know for sure that the other Postgres Operator is done with the cluster (waiting for the resync does not prevent the race condition, though it is less likely). So maybe the appropriate response should be "don't change theacid.zalan.do/controller annotation"?

Start in pkg/controller/postgresql.go at postgresqlUpdate and postgresqlCheck, then trace the EventSync path. Reproduce the controller-ID annotation change and verify that the cluster is processed immediately rather than at the next resync, while considering the stated ownership and race-condition concern.