On Mon, Apr 21, 2025 at 11:01 PM Masahiko Sawada <sawada.m...@gmail.com> 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. > > 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'. > > > 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. For consistency, we might need to > invalidate logical slots during server startup if the WAL level is > insufficient. > > Alternatively, we could permit logical decoding on the standby even > with wal_level set to 'replica'. However, this would necessitate > invalidating all logical replication slots during promotion, > potentially extending downtime during failover. >
BTW, did we consider the idea to automatically transition to 'logical' when the first logical slot is created and transition back to 'replica' when last logical slot gets dropped? I see some ideas around this last time we discussed this topic. [1] - https://www.postgresql.org/message-id/CAA4eK1J0we5qsZ-ZOwXPbZyvwdWbnT43knO2Cxidia2aHxZSJw%40mail.gmail.com -- With Regards, Amit Kapila.
