From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Date: | 2025-01-15 04:34:50 |
Message-ID: | CALDaNm1fWiwQcopeFuL4gfX8VRGWW5axm52j9T=A-RreikTBew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 14 Jan 2025 at 03:03, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-01-15 04:45:05 | Re: Infinite loop in XLogPageRead() on standby |
Previous Message | Amit Kapila | 2025-01-15 04:08:12 | Re: Conflict detection for update_deleted in logical replication |