Re: Synchronizing slots from primary to standby
От | Drouvot, Bertrand |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | 36192d4b-5861-4758-a930-5a175fd3bafc@gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
Hi, On 9/25/23 10:44 AM, Drouvot, Bertrand wrote: > Hi, > > On 9/23/23 3:38 AM, Amit Kapila wrote: >> On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand >> <bertranddrouvot.pg@gmail.com> wrote: >> There is a difference here that we also need to prevent removal of >> rows required by sync_slots. That could be achieved by physical slot >> (and hot_standby_feedback). So, having a requirement to have physical >> slot doesn't sound too unreasonable to me. Otherwise, we need to >> invent some new mechanism of having some sort of placeholder slot to >> avoid removal of required rows. > > Thinking about it, I wonder if removal of required rows is even possible > given that: > > - we don't allow to logical decode from a sync slot > - sync slot catalog_xmin <= its primary counter part catalog_xmin > - its primary counter part prevents rows removal thanks to its own catalog_xmin > - a sync slot is removed as soon as its primary counter part is removed > > In that case I'm not sure how rows removal on the primary could lead to remove rows > required by a sync slot. Am I missing something? Do you have a scenario in mind? Please forget the above questions, it's in fact pretty easy to remove rows on the primary that would be needed by a sync slot. I do agree that having a requirement to have physical slot does not sound unreasonable then. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: