Hi,
On 12/4/23 4:33 AM, Zhijie Hou (Fujitsu) wrote:
On Wednesday, November 29, 2023 5:55 PM Drouvot, Bertrand
<bertranddrouvot...@gmail.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
