Re: Fix slot synchronization with two_phase decoding enabled
От | Masahiko Sawada |
---|---|
Тема | Re: Fix slot synchronization with two_phase decoding enabled |
Дата | |
Msg-id | CAD21AoCvCw42m6UxdFA=3FgUaz_Eb+LvaYFNTbagMQJc1tHphQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Fix slot synchronization with two_phase decoding enabled ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Fix slot synchronization with two_phase decoding enabled
Re: Fix slot synchronization with two_phase decoding enabled |
Список | pgsql-hackers |
On Sun, Jun 1, 2025 at 10:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > Yet another idea is to dump the subscription with two_phase = on and > failover = false. We should do this when both options are 'true' > during the dump. As we are documenting that we always dump > createsubscription with connect as false and let users take care (see > [1] (When dumping logical replication subscriptions ...)), a similar > reasoning could be given for the failover flag. It probably would work for subscriptions but what about logical slots? If we restore two_phase=on and failover=false, the user would have to enable the failover via ALTER_REPLICATION_SLOT. I think we should avoid asking users to execute the replication commands directly. > The one more combination to consider is when someone takes a dump of > an older version and loads it into a newer version. For example, where > users dump from 17.5 and then restore in a newer version, say 17.6 > (which has our fix), the restore will fail due to newer restrictions > added by this patch. Do we need to do anything about it? A valid concern. Implementing this change could potentially render dumps created prior to version 17.5 incompatible with version 17.6 or later, which seems a significant backwards incompatibility to me. Do we have any precedence of such incompatibility? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: