On Thu, Jul 23, 2020 at 3:42 AM Amul Sul <sula...@gmail.com> wrote: > The aim of this feature is preventing new WAL records from being generated, > not > preventing them from being flushed to disk, or streamed to standbys, or > anything > else. The rest should happen as normal. > > If you can't flush WAL, then you might not be able to evict some number of > buffers, which in the worst case could be large. That's because you can't > evict > a dirty buffer until WAL has been flushed up to the buffer's LSN (otherwise, > you wouldn't be following the WAL-before-data rule). And having a potentially > large number of unevictable buffers around sounds terrible, not only for > performance, but also for having the system keep working at all.
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. WAL should still stream to the secondary of course, even after you mark the primary as read-only. > Read-only is for the queries. 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. > The intention is to change the system to read-only ASAP; the checkpoint will > make it much slower. I agree - if one needs that speed, then they can do the equivalent of: ALTER SYSTEM SET read_only to 'wal'; and the expensive checkpoint you mentioned can be avoided. > I don't think we can skip control file updates that need to make read-only > state persistent across the restart. I was referring to control file updates post the read-only state change. Any updates done as a part of the state change is totally cool. Regards, Soumyadeep (VMware)