Amit Kapila <amit.kapila16@gmail.com> writes:
> On Tue, Jun 16, 2020 at 7:26 PM amul sul <sulamul@gmail.com> wrote:
>> Attached patch proposes $Subject feature which forces the system into read-only
>> mode where insert write-ahead log will be prohibited until ALTER SYSTEM READ
>> WRITE executed.
> Do we prohibit the checkpointer to write dirty pages and write a
> checkpoint record as well?
I think this is a really bad idea and should simply be rejected.
Aside from the points you mention, such a switch would break autovacuum.
It would break the ability for scans to do HOT-chain cleanup, which would
likely lead to some odd behaviors (if, eg, somebody flips the switch
between where that's supposed to happen and where an update needs to
happen on the same page). It would break the ability for indexscans to do
killed-tuple marking, which is critical for performance in some scenarios.
It would break the ability to set tuple hint bits, which is even more
critical for performance. It'd possibly break, or at least complicate,
logic in index AMs to deal with index format updates --- I'm fairly sure
there are places that will try to update out-of-date data structures
rather than cope with the old structure, even in nominally read-only
searches.
I also think that putting such a thing into ALTER SYSTEM has got big
logical problems. Someday we will probably want to have ALTER SYSTEM
write WAL so that standby servers can absorb the settings changes.
But if writing WAL is disabled, how can you ever turn the thing off again?
Lastly, the arguments in favor seem pretty bogus. HA switchover normally
involves just killing the primary server, not expecting that you can
leisurely issue some commands to it first. Commands that involve a whole
bunch of subtle interlocking --- and, therefore, aren't going to work if
anything has gone wrong already anywhere in the server --- seem like a
particularly poor thing to be hanging your HA strategy on. I also wonder
what this accomplishes that couldn't be done much more simply by killing
the walsenders.
In short, I see a huge amount of complexity here, an ongoing source of
hard-to-identify, hard-to-fix bugs, and not very much real usefulness.
regards, tom lane