É correto supor que o modo de desligamento smart, ou seja,
pg_ctlcluster 9.6 main stop
não funcionará para servidores em espera PostgreSQL e que sempre terei que usar o modo de desligamento fast(ou immediate):
pg_ctlcluster 9.6 main stop -m fast
Estou assumindo isso por causa deste parágrafo em pg_ctl(1):
Três métodos de desligamento diferentes podem ser selecionados com a opção -m. O modo “inteligente” aguarda a desconexão de todos os clientes ativos e a conclusão de qualquer backup online. Se o servidor estiver em espera ativa, a recuperação e a replicação de streaming serão encerradas assim que todos os clientes forem desconectados. O modo “Rápido” (o padrão) não espera que os clientes se desconectem e encerrará um backup online em andamento. Todas as transações ativas são revertidas e os clientes são desconectados à força e, em seguida, o servidor é desligado. O modo “Imediato” abortará todos os processos do servidor imediatamente, sem um desligamento limpo. Isso levará a uma execução de recuperação de falhas na próxima reinicialização.
Estou hesitando um pouco, porque até agora estou acostumado a usar fast(ou immediate) apenas em casos de emergências relativas.
Um receptor WAL não é um cliente ativo nem um backup online. Portanto, o chamado desligamento "inteligente" executado no mestre não aguardará indefinidamente que o receptor WAL desapareça por conta própria. Em vez disso, ele desconectará ativamente o receptor WAL. Isso é praticamente a última coisa que ele faz - ele aguarda a conclusão do ponto de verificação de desligamento e transmite o WAL que contém esse registro de ponto de verificação para a réplica e, em seguida, o desconecta.
Se você estiver preocupado com "Se o servidor estiver em espera ativa, a recuperação e a replicação de streaming serão encerradas assim que todos os clientes forem desconectados", isso descreve o que acontece quando o desligamento inteligente é iniciado na réplica, não no mestre. O mestre nunca está "em hot standby", que é um status em que apenas uma réplica pode estar.