Recovery not moving forward after changing clone timestamp

[yelhouti]

Please, answer some short questions which should help us to understand your problem / question better?

• Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.6.3
• Where do you run it - cloud or metal? Kubernetes or OpenShift? Bare Metal K8s
• Are you running Postgres Operator in production? yes
• Type of issue? Bug report

I truncated the wrong schema in a production database (as smart people do) and I am trying to do a point-intime recovery. I was able to recreate a backup cluster on a different namespace, and I am to see that data. Want I want to do is make sure that no data is missed between the time I recovered to the time I truncated. I can't figure out the exact time I did the truncate using pg_waldump so I decided to step one second by modifying clone.timestamp 1 second at a time unless I can't find the data. But it seems like changing the timestamp and re-applying the crd doesn't d the trick. And deleting and recreating the crd, takes too long because it needs to re-download and extract the base backup...

Is there a smarter way to creep forward until I reach the correct timestamp ? Could the operator be fixed to do that as one would expect ?