On Tue, 14 Jan 2025 at 03:03, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > Yeah, delegating the activation to the background process such as the > checkpointer would also be one solution. This would work with the > approach that we enable the logical decoding via > pg_activate_logical_decoding(). On the other hand, if we support > automatically enabling the logical decoding (and logical info logging) > when the first logical slot is created, we might want to have the > process who is creating the logical slot activate the logical decoding > too.
One possible approach is to delegate the task of updating the wal level to include logical decoding information during the creation of the first logical replication slot also to a background process (e.g., the checkpoint process) and wait until the wal level has been updated and reaches ready state. Additionally, we could introduce a new optional parameter during slot creation to specify whether we should roll back changes related to updating the WAL level in case of failure. If a rollback is needed, we could invoke the logical_decoding_activation_abort_callback. By default, the rollback could be set to false, since in most failure scenarios, the user will likely attempt to create the slot again immediately. By then, the WAL level may have already been updated, eliminating the need to wait for any new long-running transactions. An alternative approach could be to skip the rollback of logical info logging during logical replication slot creation in case of failure, without introducing a rollback parameter. This is because there may be concurrent transactions (e.g., parallel slot creation or pg_activate_logical_decoding from different sessions) that would also fail. In such cases, the user could be allowed to call pg_deactivate_logical_decoding if needed. Regards, Vignesh
