About the reboot_host_post_delay default of 5 min

[pat-s]

Isn't this a much too long wait?

I can't infer what exactly is being waited for even after reading #580, but whatever it is, I wonder why 5 min was set as the default?

As a user I would expect PG to handle this gracefully even with reboot_host_post_delay: 0, even though this might not be the best case, as you wouldn't have added this option in the first place then.

I understand that medium-large clusters might need a longer time here, but then I think it would be better to make this value relative to the DB/cache size somehow?

Can you share how a problematic scenario would look like where there hasn't been enough time given to warm up the caches for medium/large instances? This would make it easier for users to understand this task 🙂️

[vitabaks]

Autobase is also used with large databases (tens of terabytes) and workloads exceeding 100K TPS.
Before proceeding with a rolling update, it’s important to introduce a short pause between server restarts — otherwise, rebooting all servers too quickly may lead to service degradation.

You’re not required to use the default delay — you can override it. For example, in my production setup, it’s set to 10 minutes.

[pat-s]

But why exactly? Yes, its about caches but why would a missing wait time for caches cause a possible service degradation, especially when servers are updated sequentially and through this implicitly have a short time of catching up before the next step starts.

a short pause

5 mins isn't a short pause (?)

I am asking again (because you didn't answer that): why not make the pause time dynamic and relative to the DB size?

You’re not required to use the default delay — you can override it. For example, in my production setup, it’s set to 10 minutes.

I am aware and its good that the option exists, but I am asking about the default value. What is the justification for this to be 5 min?
Default values are used by > 90% of all users and they are important and should have a practical reasoning instead of following a gut feeling/making them "large enough".

[vitabaks]

why would a missing wait time for caches cause a possible service degradation

Because updating without a pause takes place quite quickly, and thus you will be in a situation where the entire cluster was rebooted almost at the same time and all replicas will have poorly warmed up shared_buffers.

5 mins isn't a short pause (?)

The 5-minute value can be justified in much the same way as the default shared_buffers = 128MB — it’s simply a reasonable default chosen by the developers. It’s not perfect, but it’s better than having nothing set.

Further tuning should be done individually for each installation.
For example, on systems with light load and fast NVMe disks, a 1-minute delay may be sufficient. On the other hand, for setups using SSDs or even HDDs, 5 minutes might not be enough — and a longer pause could be required.

Of course, all default values are chosen to ensure a stable and functional production cluster out of the box — but they won’t be ideal for every case.

That's where individual support services can be useful.

[vitabaks]

For example, @SDV109 wants this pause to be applied in all cases — even when only PostgreSQL packages are being updated — not just during full server reboots, when caches are completely cleared, as it works now.