Re: Synchronizing slots from primary to standby
От | Amit Kapila |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAA4eK1+Y4KVBOdJ0UWPzHUUvJMVYZbbnRrhwxFN4gyqJ0dfO8A@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Synchronizing slots from primary to standby ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Список | pgsql-hackers |
On Tue, Dec 26, 2023 at 3:00 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > > I think we should be able to detect it if we want but do we want to > > add this restriction considering that users can always install the > > required plugins after standby gets promoted? I think we can do either > > way in this case but as we are not going to use these slots till the > > standby node is promoted, it seems okay to validate the plugins after > > promotion once users use the synced slots. > > Personally it should be detected, but I want to hear opinions from others. > Below are my reasons: > > 1) > We can avoid a possibility that users miss the installation of plugins. Basically > we should detect before the issue will really occur. > > 2) > Rules around here might be inconsistent. Slots which will be synchronized can be > created either way: > > a) manual creation via SQL function, or > b) automatic creation by slotsync worker. > > In case of a), the decoding context is created when creation so that the plugin > must be installed. Case b), however, we allow not to install beforehand. I felt > it might be confused for users. Thought? > I think the (a) way could lead to the setting of incorrect LSNs (restart_LSN and confirmed_flush_lsn) considering they are not copied from the primary. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: