Re: pg_upgrade and logical replication

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: pg_upgrade and logical replication
Дата
Msg-id CALDaNm1ZrbHaWpJwwNhDTJocRKWd3rEkgJazuDdZ9Z-WdvonFg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: pg_upgrade and logical replication  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Ответы RE: pg_upgrade and logical replication  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
RE: pg_upgrade and logical replication  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Список pgsql-hackers
On Thu, 27 Apr 2023 at 13:18, Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Julien,
>
> Thank you for updating the patch! Followings are my comments.
>
> 01. documentation
>
> In this page steps to upgrade server with pg_upgrade is aligned. Should we write
> down about subscriber? IIUC, it is sufficient to just add to "Run pg_upgrade",
> like "Apart from streaming replication standby, subscriber node can be upgrade
> via pg_upgrade. At that time we strongly recommend to use --preserve-subscription-state".

Now this option has been removed and made default

> 02. AlterSubscription
>
> I agreed that oid must be preserved between nodes, but I'm still afraid that
> given oid is unconditionally trusted and added to pg_subscription_rel.
> I think we can check the existenec of the relation via SearchSysCache1(RELOID,
> ObjectIdGetDatum(relid)). Of cource the check is optional, so it should be
> executed only when USE_ASSERT_CHECKING is on. Thought?

Modified

> 03. main
>
> Currently --preserve-subscription-state and --no-subscriptions can be used
> together, but the situation is quite unnatural. Shouldn't we exclude them?

This option is removed now, so this scenario will not happen

> 04. getSubscriptionTables
>
>
> ```
> +       SubRelInfo *rels = NULL;
> ```
>
> The variable is used only inside the loop, so the definition should be also moved.

This logic is changed slightly, so it needs to be kept outside

> 05. getSubscriptionTables
>
> ```
> +                       nrels = atooid(PQgetvalue(res, i, i_nrels));
> ```
>
> atoi() should be used instead of atooid().

Modified

> 06. getSubscriptionTables
>
> ```
> +                       subinfo = findSubscriptionByOid(cur_srsubid);
> +
> +                       nrels = atooid(PQgetvalue(res, i, i_nrels));
> +                       rels = pg_malloc(nrels * sizeof(SubRelInfo));
> +
> +                       subinfo->subrels = rels;
> +                       subinfo->nrels = nrels;
> ```
>
> Maybe it never occurs, but findSubscriptionByOid() can return NULL. At that time
> accesses to their attributes will lead the Segfault. Some handling is needed.

This should not happen, added a fatal error in this case.

> 07. dumpSubscription
>
> Hmm, SubRelInfos are still dumped at the dumpSubscription(). I think this style
> breaks the manner of pg_dump. I think another dump function is needed. Please
> see dumpPublicationTable() and dumpPublicationNamespace(). If you have a reason
> to use the style, some comments to describe it is needed.

Modified

> 08. _SubRelInfo
>
> If you will address above comment, DumpableObject must be added as new attribute.

Modified

> 09. check_for_subscription_state
>
> ```
> +                       for (int i = 0; i < ntup; i++)
> +                       {
> +                               is_error = true;
> +                               pg_log(PG_WARNING,
> +                                          "\nWARNING:  subscription \"%s\" has an invalid remote_lsn",
> +                                          PQgetvalue(res, 0, 0));
> +                       }
> ```
>
> The second argument should be i to report the name of subscription more than 2.

Modified

> 10. 003_subscription.pl
>
> ```
> $old_sub->wait_for_subscription_sync($publisher, 'sub');
>
> my $result = $old_sub->safe_psql('postgres',
>     "SELECT COUNT(*) FROM pg_subscription_rel WHERE srsubstate != 'r'");
> is ($result, qq(0), "All tables in pg_subscription_rel should be in ready state");
> ```
>
> I think there is a possibility to cause a timing issue, because the SELECT may
> be executed before srsubstate is changed from 's' to 'r'. Maybe poll_query_until()
> can be used instead.

Modified

> 11. 003_subscription.pl
>
> ```
> command_ok(
>         [
>                 'pg_upgrade', '--no-sync',        '-d', $old_sub->data_dir,
>                 '-D',         $new_sub->data_dir, '-b', $bindir,
>                 '-B',         $bindir,            '-s', $new_sub->host,
>                 '-p',         $old_sub->port,     '-P', $new_sub->port,
>                 $mode,
>                 '--preserve-subscription-state',
>                 '--check',
>         ],
>         'run of pg_upgrade --check for old instance with correct sub rel');
> ```
>
> Missing check of pg_upgrade_output.d?

Modified

> And maybe you missed to run pgperltidy.

It has been run for the new patch.

The attached v7 patch has the changes for the same.

Regards,
Vignesh

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Correct the documentation for work_mem
Следующее
От: vignesh C
Дата:
Сообщение: Re: pg_upgrade and logical replication