On Mon, Jan 13, 2025 at 2:52 PM vignesh C <vignes...@gmail.com> wrote: > > I felt that the only disadvantage with this approach is that we > currently wait for all in-progress transactions to complete before > enabling logical decoding. If a long-running transaction exists and > the session enabling logical decoding fails—due to factors like > statement_timeout, transaction_timeout, > idle_in_transaction_session_timeout, idle_session_timeout, or any > other failure. This would require restarting the wait. During this > time, there's a risk that a new long-running transaction could start, > further delaying the process. Probably this could be solved if the > waiting is done from any of the background processes through > PGC_SIGHUP. While this type of failure is likely rare, I’m unsure > whether we should consider this scenario.
A related question: While the operation is waiting for already running transactions to end, the backends whose transactions have finished may start new transactions. When we switch WAL from 'replica' to 'logical', there may be some transactions running. Will this lead to WAL stream with mixes WAL records - some with logical information and some without? Do we need to adjust logical decoding to tackle this situation? Is there a chance that some WAL from same transaction have logical information and some do not? -- Best Wishes, Ashutosh Bapat
