Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAD21AoC0RMOnu-o9ibgyMH7Dbm4s_2L8+iuwNbCsMyifdFLXEA@mail.gmail.com
Whole thread Raw
In response to RE: Skipping logical replication transactions on subscriber side  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Wed, Oct 20, 2021 at 12:03 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> On Mon, Oct 18, 2021 9:34 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > I've attached updated patches that incorporate all comments I got so far.
>
> Hi,
>
> Here are some minor comments for the patches.

Thank you for the comments!

>
> v17-0001-Add-a-subscription-errors-statistics-view-pg_sta.patch
>
> 1)
>
> +       /* Clean up */
> +       if (not_ready_rels != NIL)
> +               list_free_deep(not_ready_rels);
>
> Maybe we don't need the ' if (not_ready_rels != NIL)' check as
> list_free_deep will do this check internally.

Agreed.

>
> 2)
>
> +       for (int i = 0; i < msg->m_nentries; i++)
> +       {
> +               HASH_SEQ_STATUS sstat;
> +               PgStat_StatSubWorkerEntry *wentry;
> +
> +               /* Remove all worker statistics of the subscription */
> +               hash_seq_init(&sstat, subWorkerStatHash);
> +               while ((wentry = (PgStat_StatSubWorkerEntry *) hash_seq_search(&sstat)) != NULL)
> +               {
> +                       if (wentry->key.subid == msg->m_subids[i])
> +                               (void) hash_search(subWorkerStatHash, (void *) &(wentry->key),
> +                                                                  HASH_REMOVE, NULL);
>
> Would it be a little faster if we scan hashtable in outerloop and
> scan the msg in innerloop ?
> Like:
> while ((wentry = (PgStat_StatSubWorkerEntry *) hash_seq_search(&sstat)) != NULL)
> {
>         for (int i = 0; i < msg->m_nentries; i++)
>         ...
>

Agreed.

>
> v17-0002-Add-RESET-command-to-ALTER-SUBSCRIPTION-command
>
> 1)
> I noticed that we cannot RESET slot_name while we can SET it.
> And the slot_name have a default behavior that " use the name of the subscription for the slot name.".
> So, is it possible to support RESET it ?

Hmm, I'm not sure resetting slot_name is useful. I think that it’s
common to change the slot name to NONE  by ALTER SUBSCRIPTION and vise
versa. But I think resetting the slot name (i.g., changing a
non-default name to the default name) is not the common use case. If
the user wants to do that, it seems safer to explicitly specify the
slot name using by ALTER SUBSCRIPTION ... SET (slot_name = 'XXX').

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [PATCH] Fix memory corruption in pg_shdepend.c
Next
From: Dilip Kumar
Date:
Subject: Re: pgsql: Document XLOG_INCLUDE_XID a little better