Horton

Thread

Commits

  1. Doc: Fix the mistakes in the subscription's failover option.

  1. Correction in doc of failover ready steps

    shveta malik <shveta.malik@gmail.com> — 2024-07-22T05:16:53Z

    Hi,

We have a query in failover-ready doc referring to
pg_subscription_rel. Unlike pg_subscription, pg_subscription_rel gives
results only when connected to the database having the
subscription(s). If we run the concerned query on any other database,
it will give incomplete results i.e. it will give info on main slots
leaving table sync slots (if any).
Thus the failover-ready steps which queries pg_subscription_rel need
to mention that the concerned query needs to be run on the database(s)
that includes the failover enabled subscription(s).  Corrected the doc
for the same.

thanks
Shveta

  2. Re: Correction in doc of failover ready steps

    shveta malik <shveta.malik@gmail.com> — 2024-07-22T05:29:28Z

    On Mon, Jul 22, 2024 at 10:46 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> Hi,
>
> We have a query in failover-ready doc referring to
> pg_subscription_rel. Unlike pg_subscription, pg_subscription_rel gives
> results only when connected to the database having the
> subscription(s). If we run the concerned query on any other database,
> it will give incomplete results i.e. it will give info on main slots
> leaving table sync slots (if any).
> Thus the failover-ready steps which queries pg_subscription_rel need
> to mention that the concerned query needs to be run on the database(s)
> that includes the failover enabled subscription(s).  Corrected the doc
> for the same.

On rethinking, since pg_subscription query needs to be run only once
on *any* database to get combined results of all main slots while
pg_subscription_rel query needs to be run on each database having
concerned subscription (and table), does it makes sense to separate
the 2 queries instead of having UNION ? Thoughts?

thanks
Shveta

  3. Re: Correction in doc of failover ready steps

    Amit Kapila <amit.kapila16@gmail.com> — 2024-07-22T11:12:55Z

    On Mon, Jul 22, 2024 at 10:59 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Mon, Jul 22, 2024 at 10:46 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > Hi,
> >
> > We have a query in failover-ready doc referring to
> > pg_subscription_rel. Unlike pg_subscription, pg_subscription_rel gives
> > results only when connected to the database having the
> > subscription(s). If we run the concerned query on any other database,
> > it will give incomplete results i.e. it will give info on main slots
> > leaving table sync slots (if any).
> > Thus the failover-ready steps which queries pg_subscription_rel need
> > to mention that the concerned query needs to be run on the database(s)
> > that includes the failover enabled subscription(s).  Corrected the doc
> > for the same.
>
> On rethinking, since pg_subscription query needs to be run only once
> on *any* database to get combined results of all main slots while
> pg_subscription_rel query needs to be run on each database having
> concerned subscription (and table), does it makes sense to separate
> the 2 queries instead of having UNION ? Thoughts?
>

I think so. Let's see if Hou-San or anyone else has better ideas to
fetch this information.

-- 
With Regards,
Amit Kapila.

  4. RE: Correction in doc of failover ready steps

    Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> — 2024-07-23T02:44:24Z

    On Monday, July 22, 2024 7:13 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> 
> On Mon, Jul 22, 2024 at 10:59 AM shveta malik <shveta.malik@gmail.com>
> wrote:
> >
> > On Mon, Jul 22, 2024 at 10:46 AM shveta malik <shveta.malik@gmail.com>
> wrote:
> > >
> > > Hi,
> > >
> > > We have a query in failover-ready doc referring to
> > > pg_subscription_rel. Unlike pg_subscription, pg_subscription_rel
> > > gives results only when connected to the database having the
> > > subscription(s). If we run the concerned query on any other
> > > database, it will give incomplete results i.e. it will give info on
> > > main slots leaving table sync slots (if any).
> > > Thus the failover-ready steps which queries pg_subscription_rel need
> > > to mention that the concerned query needs to be run on the
> > > database(s) that includes the failover enabled subscription(s).
> > > Corrected the doc for the same.
> >
> > On rethinking, since pg_subscription query needs to be run only once
> > on *any* database to get combined results of all main slots while
> > pg_subscription_rel query needs to be run on each database having
> > concerned subscription (and table), does it makes sense to separate
> > the 2 queries instead of having UNION ? Thoughts?
> >
> 
> I think so. Let's see if Hou-San or anyone else has better ideas to fetch this
> information.

I also agree that separating the 2 queries makes sense.

Best Regards,
Hou zj

  5. Re: Correction in doc of failover ready steps

    shveta malik <shveta.malik@gmail.com> — 2024-07-23T04:10:46Z

    On Tue, Jul 23, 2024 at 8:14 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> I also agree that separating the 2 queries makes sense.

Please find the patch with the suggested change.

thanks
Shveta

  6. Re: Correction in doc of failover ready steps

    Amit Kapila <amit.kapila16@gmail.com> — 2024-07-23T11:40:25Z

    On Tue, Jul 23, 2024 at 9:40 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Tue, Jul 23, 2024 at 8:14 AM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > I also agree that separating the 2 queries makes sense.
>
> Please find the patch with the suggested change.
>

One minor comment:
-     if the table copy is finished (See <xref
linkend="catalog-pg-subscription-rel"/>).
+     On the subscriber node, use the following SQL to identify which main
+     slots should be synced to the standby that we plan to promote. This query

Shall we refer to these slots as replication slots instead of main
slots in the above sentence? We don't have a main slot terminology at
other places, so it would be better not to introduce a new one. I know
that it was introduced in the original commit but it seems better to
change if we agree.




-- 
With Regards,
Amit Kapila.

  7. Re: Correction in doc of failover ready steps

    shveta malik <shveta.malik@gmail.com> — 2024-07-24T02:56:01Z

    On Tue, Jul 23, 2024 at 5:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> One minor comment:
> -     if the table copy is finished (See <xref
> linkend="catalog-pg-subscription-rel"/>).
> +     On the subscriber node, use the following SQL to identify which main
> +     slots should be synced to the standby that we plan to promote. This query
>
> Shall we refer to these slots as replication slots instead of main
> slots in the above sentence? We don't have a main slot terminology at
> other places, so it would be better not to introduce a new one. I know
> that it was introduced in the original commit but it seems better to
> change if we agree.

Yes, it makes sense. Please find the patch with this change.

thanks
SHveta

  8. RE: Correction in doc of failover ready steps

    Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> — 2024-07-24T03:32:12Z

    On Wednesday, July 24, 2024 10:56 AM shveta malik <shveta.malik@gmail.com> wrote:
> 
> On Tue, Jul 23, 2024 at 5:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > One minor comment:
> > -     if the table copy is finished (See <xref
> > linkend="catalog-pg-subscription-rel"/>).
> > +     On the subscriber node, use the following SQL to identify which main
> > +     slots should be synced to the standby that we plan to promote.
> > + This query
> >
> > Shall we refer to these slots as replication slots instead of main
> > slots in the above sentence? We don't have a main slot terminology at
> > other places, so it would be better not to introduce a new one. I know
> > that it was introduced in the original commit but it seems better to
> > change if we agree.
> 
> Yes, it makes sense. Please find the patch with this change.

Thanks for the patch.

Here is one comment:

The second query has a condition 'WHERE slot_name IS NOT NULL', but I
think it belongs to the first query. Because the slot_name of second query
is built by CONCAT() which means it should be valid, while the first query's
subslotname could be NULL if user executed ALTER SUB SET (slot_name = NONE).

Apart from above, it looks good to me.

Best Regards,
Hou zj

  9. Re: Correction in doc of failover ready steps

    shveta malik <shveta.malik@gmail.com> — 2024-07-24T04:10:49Z

    On Wed, Jul 24, 2024 at 9:02 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> Thanks for the patch.
>
> Here is one comment:
>
> The second query has a condition 'WHERE slot_name IS NOT NULL', but I
> think it belongs to the first query. Because the slot_name of second query
> is built by CONCAT() which means it should be valid, while the first query's
> subslotname could be NULL if user executed ALTER SUB SET (slot_name = NONE).
>

Thanks for pointing it out. Please find a new patch with this change.

Also corrected the commit message in this patch.

thanks
Shveta