Re: Linkify mentions of the primary/subscriber's max_replication_slots - Mailing list pgsql-hackers

From Tristan Partin
Subject Re: Linkify mentions of the primary/subscriber's max_replication_slots
Date
Msg-id D5JIW48PKEB2.2V6EMZ336BINA@partin.io
Whole thread Raw
In response to Re: Linkify mentions of the primary/subscriber's max_replication_slots  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon Nov 11, 2024 at 5:53 AM CST, Amit Kapila wrote:
> On Thu, Nov 7, 2024 at 4:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Thu, Nov 7, 2024 at 9:36 AM Tristan Partin <tristan@partin.io> wrote:
>> >
>> >
>> > Here is a patch which does so.
>> >
>>
>> <para>
>>           Note that this parameter also applies on the subscriber side, but with
>> -         a different meaning.
>> +         a different meaning. See <xref
>> linkend="guc-max-replication-slots-subscriber"/>
>> +         in <xref linkend="runtime-config-replication-sender"/> for more
>> +         details.
>>          </para>
>>         </listitem>
>>        </varlistentry>
>> @@ -5215,7 +5217,9 @@ ANY <replaceable
>> class="parameter">num_sync</replaceable> ( <replaceable class="
>>
>>         <para>
>>          Note that this parameter also applies on a sending server, but with
>> -        a different meaning.
>> +        a different meaning. See <xref linkend="guc-max-replication-slots"/>
>> +        in <xref linkend="runtime-config-replication-primary"/> for more
>> +        details.
>>
>> <xref linkend="runtime-config-replication-sender"/> and <xref
>> linkend="runtime-config-replication-primary"/> are incorrect. They
>> should be instead <xref
>> linkend="runtime-config-replication-subscriber"/> and <xref
>> linkend="runtime-config-replication-sender"/>.
>>
>
> I have made the required changes and pushed the patch.

Thanks for your help in getting this over the line Amit 😄.

--
Tristan Partin
Neon (https://neon.tech)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: index prefetching
Next
From: Ivan Kush
Date:
Subject: Re: Replace IN VALUES with ANY in WHERE clauses during optimization