Re: Synchronizing slots from primary to standby

Hi,

On 9/23/23 3:38 AM, Amit Kapila wrote:
> On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>
>> Thanks for all the work that has been done on this feature, and sorry
>> to have been quiet on it for so long.
>>
>> On 9/18/23 12:22 PM, shveta malik wrote:
>>> On Wed, Sep 13, 2023 at 4:48 PM Hayato Kuroda (Fujitsu)
>>> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>>>> Right, but I wanted to know why it is needed. One motivation seemed to know the
>>>> WAL location of physical standby, but I thought that struct WalSnd.apply could
>>>> be also used. Is it bad to assume that the physical walsender always exists?
>>>>
>>>
>>> We do not plan to target this case where physical slot is not created
>>> between primary and physical-standby in the first draft. In such a
>>> case, slot-synchronization will be skipped for the time being. We can
>>> extend this functionality (if needed) later.
>>>
>>
>> I do think it's needed to extend this functionality. Having physical slot
>> created sounds like a (too?) strong requirement as:
>>
>> - It has not been a requirement for Logical decoding on standby so that could sounds weird
>> to require it for sync slot (while it's not allowed to logical decode from sync slots)
>>
>
> 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?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com