Re: Exit walsender before confirming remote flush in logical replication
От | Dilip Kumar |
---|---|
Тема | Re: Exit walsender before confirming remote flush in logical replication |
Дата | |
Msg-id | CAFiTN-uBV+TG4Kf-NEuLkTQARJ+sDA2u-4n5T_ZR0WxghAq6FA@mail.gmail.com обсуждение исходный текст |
Ответ на | Exit walsender before confirming remote flush in logical replication ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: Exit walsender before confirming remote flush in logical replication
|
Список | pgsql-hackers |
On Thu, Dec 22, 2022 at 11:16 AM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > In case of logical replication, however, we cannot support the use-case that > switches the role publisher <-> subscriber. Suppose same case as above, additional > transactions are committed while doing step2. To catch up such changes subscriber > must receive WALs related with trans, but it cannot be done because subscriber > cannot request WALs from the specific position. In the case, we must truncate all > data in new subscriber once, and then create new subscription with copy_data > = true. > > Therefore, I think that we can ignore the condition for shutting down the > walsender in logical replication. > +1 for the idea. - * Note that if we determine that there's still more data to send, this - * function will return control to the caller. + * Note that if we determine that there's still more data to send or we are in + * the physical replication more, this function will return control to the + * caller. I think in this comment you meant to say 1. "or we are in physical replication mode and all WALs are not yet replicated" 2. Typo /replication more/replication mode -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: