On Fri, Jul 24, 2020 at 7:34 AM Robert Haas <robertmh...@gmail.com> wrote:
> > On Thu, Jul 23, 2020 at 12:11 PM Soumyadeep Chakraborty > <soumyadeep2...@gmail.com> wrote: > > In the read-only level I was suggesting, I wasn't suggesting that we > > stop WAL flushes, in fact we should flush the WAL before we mark the > > system as read-only. Once the system declares itself as read-only, it > > will not perform any more on-disk changes; It may perform all the > > flushes it needs as a part of the read-only request handling. > > I think that's already how the patch works, or at least how it should > work. You stop new writes, flush any existing WAL, and then declare > the system read-only. That can all be done quickly. > True, except for the fact that it allows dirty buffers to be flushed after the ALTER command returns. > > What I am saying is it doesn't have to be just the queries. I think we > > can cater to all the other use cases simply by forcing a checkpoint > > before marking the system as read-only. > > But that part can't, which means that if we did that, it would break > the feature for the originally intended use case. I'm not on board > with that. > Referring to the options you presented in [1]: I am saying that we should allow for both: with a checkpoint (#2) (can also be #3) and without a checkpoint (#1) before having the ALTER command return, by having different levels of read-onlyness. We should have syntax variants for these. The syntax should not be an ALTER SYSTEM SET as you have pointed out before. Perhaps: ALTER SYSTEM READ ONLY; -- #2 or #3 ALTER SYSTEM READ ONLY WAL; -- #1 ALTER SYSTEM READ WRITE; or even: ALTER SYSTEM FREEZE; -- #2 or #3 ALTER SYSTEM FREEZE WAL; -- #1 ALTER SYSTEM UNFREEZE; Regards, Soumyadeep (VMware) [1] http://postgr.es/m/ca+tgmoz-c3dz9qwhwmm4bc36n4u0xz2oyenewmf+bwokbyd...@mail.gmail.com