Need add more patroni params, otherwise, large-scale database cloning cannot be performed

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.8.2
• **Where do you run it - cloud or metal? Kubernetes or OpenShift?
  OpenShift
• **Are you running Postgres Operator in production?
  yes
• Type of issue?
  Bug report

Hi, team!

We have a timescaledb database running on our production database with postgres-operator, which currently has 100G of data storage.
we found that a clone operation trying to pull backup data from Minio did not successfully start the database. After doing a log review and a patroni configuration check, we found that it appeared that the master_start_timeout (in patroni 2.1.4) parameter of patroni was causing the problem (this value defaults to 300s and our database was doing a lot of writes on a daily basis, resulting in a relatively large wal files. And after restored the database, the database would start from Minio to continue pulling WAL on startup causing it to take a very long time to catch up to the original database).

We have tried to add master_start_timeout and found that the operator currently seems to support only a small number of patroni parameters.

Is there any way we can configure the master_start_timeout parameter without modifying the codes, or is it possible for the community to add a variable that would allow users to adjust the parameter according to the official patroni configuration?

No file or test is named in the issue. Start by locating how the operator exposes Patroni parameters and how database cloning restores from Minio; verify the supported configuration path for master_start_timeout. Done means users can adjust this value and large database clones can start and catch up successfully.