Thanks for chiming in.
On Thu, Jun 23, 2022 at 04:19:45PM +0100, Simon Riggs wrote:
> I don't understand why you need this patch at all.
>
> Since you have automation, you can use that layer to automatically
> restart all standbys at once, if you choose, without any help or
> hindrance from PostgreSQL.
>
> But I really don't want you to do that, since that results in loss of
> availability of the service. I'd like you to try a little harder and
> automate this in a way that allows the service to continue with some
> standbys available while others restart.
>
> All this feature does is allow you to implement things in a lazy way
> that causes a loss of availability for users. I don't think that is of
> benefit to PostgreSQL users, so -1 from me, on this patch (only),
> sorry about that.
Overall, this is intended for users that care more about keeping WAL replay
caught up than a temporary loss of availability due to a restart. Without
this, I'd need to detect that WAL replay has paused due to insufficient
parameters and restart Postgres. If І can configure Postgres to
automatically shut down in these scenarios, my automation can skip right to
adjusting the parameters and starting Postgres up. Of course, if you care
more about availability, you'd keep this parameter set to the default
(pause) and restart on your own schedule.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com