Re: Synchronizing slots from primary to standby

Hi,

On 12/4/23 4:33 AM, Zhijie Hou (Fujitsu) wrote:
> On Wednesday, November 29, 2023 5:55 PM Drouvot, Bertrand <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
>> I think I'm fine with documenting the fact that the user should not change the
>> failover value. But if he does change it (because at the end nothing prevents it
>> to do so) then I think the meaning of subfailoverstate should still make sense.
>>
>> One way to achieve this could be to change its meaning? Say rename it to say
>> subfailovercreationstate (to reflect the fact that it was the state at the creation
>> time) and change messages like:
>>
>> "
>> ALTER SUBSCRIPTION with refresh and copy_data is not allowed when failover
>> is enabled "
>>
>> to something like
>>
>> "
>> ALTER SUBSCRIPTION with refresh and copy_data is not allowed for
>> subscription created with failover enabled"
>> "
>>
>> and change the doc accordingly.
>>
>> What do you think?

> I think document the case is OK because:
>
> Currently, user already can create similar inconsistency cases as we don't restrict
> user to change the slot on publisher. E.g., User could drop and recreate the
> slot used by subscription but with different setting. Or user ALTER
> SUBSCRIPTION set (slot_name) to switch to a new slot with different setting.
>
> For example, about two_phase option, user can create a subscription with
> two_phase disabled, then later it can set subscription slot_name to a new slot
> with two_phase enabled which is the similar case as the failover.
>

Yeah, right, did not think that such "inconsistency" can already happen.

So agree to keep "subfailoverstate" and "just" document the case then.

Regards,

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