Re: [DOC] Update ALTER SUBSCRIPTION documentation v3

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Robert Sjöblom <robert(dot)sjoblom(at)fortnox(dot)se>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [DOC] Update ALTER SUBSCRIPTION documentation v3
Date: 2023-06-15 02:49:22
Message-ID: CAA4eK1+JbpRzPvnYApHvNmWmJ2yf+jdoaCheUkGoEubhKX63cA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 14, 2023 at 6:52 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 14.06.23 05:09, Amit Kapila wrote:
> > The latest version looks good to me as well. I think we should
> > backpatch this change as this is a user-facing message change in docs
> > and code. What do you guys think?
>
> Isn't that a reason *not* to backpatch it?
>

I wanted to backpatch the following change which provides somewhat
accurate information about what a user needs to do when it faces an
error.
To proceed in
- this situation, disassociate the subscription from the replication slot by
- executing <literal>ALTER SUBSCRIPTION ... SET (slot_name = NONE)</literal>.
+ this situation, first <literal>DISABLE</literal> the subscription, and then
+ disassociate it from the replication slot by executing
+ <literal>ALTER SUBSCRIPTION ... SET (slot_name = NONE)</literal>.

Now, along with this change, there is a change in errhint as well
which I am not sure about whether to backpatch or not. I think we have
the following options (a) commit both doc and code change in HEAD (b)
commit both doc and code change in v17 when the next version branch
opens (c) backpatch the doc change and commit the code change in HEAD
only (d) backpatch the doc change and commit the code change in v17
(e) backpatch both the doc and code change.

What do you think?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Churyukin 2023-06-15 02:51:03 Re: Bypassing shared_buffers
Previous Message Tom Lane 2023-06-15 02:43:39 Re: Bypassing shared_buffers