On Tue, May 6, 2025 at 12:19 AM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > Hi, > > On Mon, Apr 21, 2025 at 10:31:03AM -0700, Masahiko Sawada wrote: > > I would like to discuss behavioral and user interface considerations. > > > > Upon further analysis of this patch regarding the conversion of > > wal_level to a SIGHUP parameter, I find that supporting all > > combinations of wal_level value changes might make less sense. > > Specifically, changing to or from 'minimal' would necessitate a > > checkpoint, and reducing wal_level to 'minimal' would require > > terminating physical replication, WAL archiving, and online backups. > > While these operations demand careful consideration, there seems to be > > no compelling use case for decreasing to 'minimal'. Furthermore, > > increasing wal_level from 'minimal' is typically a one-time operation > > during a database's lifetime. Therefore, we should weigh the benefits > > against the implementation complexity. > > Agree. > > > One solution is to manage the effective WAL level using two distinct > > GUC parameters: max_wal_level and wal_level. max_wal_level would be a > > POSTMASTER parameter controlling the system's maximum allowable WAL > > level, with values 'minimal', 'replica', and 'logical'. wal_level > > would function as a SIGHUP parameter managing the runtime WAL level, > > accepting values 'replica', 'logical', and 'auto'. The selected value > > must be either 'auto' or not exceed max_wal_level. When set to 'auto', > > wal_level automatically synchronizes with max_wal_level's value. This > > approach would enable online WAL level transitions between 'replica' > > and 'logical'. > > That makes sense to me. I think that 'logical' could be the default value > for max_wal_level and 'replica' the default for wal_level. > I think that would provide almost the same user experience as currently and > would > allow replica->logical change without restart. Thoughts?
Sounds reasonable default values. One thing we might want to note is that when users want to set 'minimal', they would need to change both parameters. With the defaults value wal_level='auto', users would need to simply set max_wal_level='minimal'. However, given that it's more common for users to start with 'replica' than 'minimal', probably it would make sense to have the default values you suggested. This combination of WAL levels maximize the benefit of this idea while maintaining the default behavior. One downside of this idea is that we introduce another GUC parameter, resulting in that users would need to control WAL level using two parameters, which might not be quite clear for users. > > > Regarding logical decoding on standbys, currently both primary and > > standby servers must have wal_level set to 'logical'. We need to > > determine the appropriate behavior when users decrease the WAL level > > from 'logical' to 'replica' through configuration file reload. > > > > One approach would be to invalidate all logical replication slots on > > the standby when transitioning to 'replica' WAL level. Although > > incoming WAL records from the primary would still be written at > > 'logical' level, making logical decoding technically feasible, this > > behavior seems logical as it reflects the user's intent to discontinue > > logical decoding on the standby. > > +1 > > > For consistency, we might need to > > invalidate logical slots during server startup if the WAL level is > > insufficient. > > Not sure. Currently we'd not allow the standby to start: > > " > LOG: entering standby mode > FATAL: logical replication slot "logical_slot" exists, but "wal_level" < > "logical" > HINT: Change "wal_level" to be "logical" or higher. > LOG: startup process (PID 1790508) exited with exit code 1 > " > > I think that's a good guard for configuration change mistakes. If that's a > mistake > change back to logical and start. If that's not a mistake then change back to > logical, start, change with SIGHUP. OTOH I also see the benefits of being > consistent > between SIGHUP and start. I see your point. An alternative idea would be to somehow prevent wal_level from being changed to 'replica' while there is at least one active logical slot on the standby. I'll consider this idea too. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
