On Fri, Jul 24, 2020 at 3:12 PM Soumyadeep Chakraborty
<soumyadeep2...@gmail.com> wrote:
> Ah yes. We should then have ALTER SYSTEM WAL {PERMIT|PROHIBIT}. I don't
> think we should say "READ ONLY" if we still allow on-disk file changes
> after the ALTER SYSTEM command returns (courtesy dirty buffer flushes)
> because it does introduce confusion, especially to an audience not privy
> to this thread. When people hear "read-only" they may think of static on-disk
> files immediately.They might think of a variety of things that are not a correct interpretation of what the feature does, but I think the way to handle that is to document it properly. I don't think making WAL a grammar keyword just for this is a good idea. I'm not totally stuck on this particular syntax if there's consensus on something else, but I seriously doubt that there will be consensus around adding parser keywords for this. > I don't have enough context to enumerate use cases for the advantages or > opportunities that would come with an assurance that the cluster's files > are frozen (and not covered by any existing utilities), but surely there > are some? Like the possibility of pg_upgrade on a running server while > it can entertain read-only queries? Surely, that's a nice one! I think that this feature is plenty complicated enough already, and we shouldn't make it more complicated to cater to additional use cases, especially when those use cases are somewhat uncertain and would probably require additional work in other parts of the system. For instance, I think it would be great to have an option to start the postmaster in a strictly "don't write ANYTHING" mode where regardless of the cluster state it won't write any data files or any WAL or even the control file. It would be useful for poking around on damaged clusters without making things worse. And it's somewhat related to the topic of this thread, but it's not THAT closely related. It's better to add features one at a time; you can always add more later, but if you make the individual ones too big and hard they don't get done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
