On Sun, May 18, 2025 at 4:06 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > Thanks for proposing the idea of making wal_level configurable at > runtime. But why isn't making the relevant GUCs SIGHUP-reloadable > sufficient? > > For enabling logical replication, users are already familiar with the > wal_level and max_wal_senders settings. The main issue is that > changing them currently requires a server restart. If we can address > that by making the GUCs reloadable via SIGHUP, that might be enough. >
Sure, but the challenges are huge. Consider cases like one wants to change wal_level from 'logical' to 'minimal'. See some analysis of the same in email [1]. I think it will be a much bigger and challenging project with diminishing returns as compared to the alternative we are discussing. > On the other hand, if the goal is to make the behavior fully dynamic, > then we should go all the way, decouple it from wal_level. For > example, we could start logging the extra WAL needed for logical > decoding as soon as a logical slot is created, and stop once all > logical slots are dropped, even if wal_level is still set to logical. > Yeah, this is one thing that is still under consideration. It is almost equivalent to removing wal_level as 'logical', which sounds like a compatibility break, and even if we want to do that, it is better to attempt that after the base version is committed and we get a broader consensus on the same. [1]- https://www.postgresql.org/message-id/CAD21AoAA%3DzuiajwXgXSCYQWo%3D6oY-%3DCGLaEqvpfNUTVsLen%2BCA%40mail.gmail.com -- With Regards, Amit Kapila.
