On Thu, Jul 23, 2020 at 3:57 AM Amul Sul <sula...@gmail.com> wrote: > Well, once we've initiated the change to a read-only state, we probably want > to > always either finish that change or go back to read-write, even if the process > that initiated the change is interrupted. Leaving the system in a > half-way-in-between state long term seems bad. Maybe we would have put some > background process, but choose the checkpointer in charge of making the state > change and to avoid the new background process to keep the first version patch > simple. The checkpointer isn't likely to get killed, but if it does, it will > be relaunched and the new one can clean things up. On the other hand, I agree > making the checkpointer responsible for more than one thing might not > be a good idea > but I don't think the postmaster should do the work that any > background process can > do.
+1 for doing it in a background process rather than in the backend itself (as we can't risk doing it in a backend as it can crash and won't restart and clean up as a background process would). As my co-worker pointed out to me, doing the work in the postmaster is a very bad idea as we don't want delays in serving connection requests on account of the barrier that comes with this patch. I would like to see this responsibility in a separate auxiliary process but I guess having it in the checkpointer isn't the end of the world. Regards, Soumyadeep (VMware)
