On Thu, Jul 23, 2020 at 3:42 AM Amul Sul <sulamul@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)