On Thu, Oct 5, 2023 at 6:43 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Thu, Oct 5, 2023 at 1:48 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > The other potential problem Andres pointed out is that during shutdown > > if due to some reason, the walreceiver goes down, we won't be able to > > send the required WAL and users won't be able to ensure that because > > even after restart the same situation can happen. The ideal way is to > > have something that puts the system in READ ONLY state during shutdown > > and then we can probably allow walreceivers to reconnect and receive > > the required WALs. As we don't have such functionality available and > > it won't be easy to achieve the same, we can leave this for now. > > > > Thoughts? > > You mean walreceiver for streaming replication? Or the apply workers > going down for logical replication? >
Apply workers. > > If there's yet-to-be-sent-out WAL, > pg_upgrade will fail no? How does the above scenario a problem for > pg_upgrade of a cluster with just logical replication slots? > Even, if there is a WAL yet to be sent, the walsender will simply exit as it will receive PqMsg_Terminate ('X') from standby. See ProcessRepliesIfAny(). After that shutdown checkpoint will finish. So, in this case upgrade can fail due to slots. But, I think the server should be able to succeed in consecutive runs. Does this make sense? -- With Regards, Amit Kapila.