Re: Impact of checkpointer during pg_upgrade

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Impact of checkpointer during pg_upgrade
Дата
Msg-id CAFiTN-v2xiXnUz5SxNXcE33tOx5HjLeJQRSfS5YNwmF4tDi5cw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Impact of checkpointer during pg_upgrade  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Impact of checkpointer during pg_upgrade  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Tue, Sep 5, 2023 at 9:38 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Sep 4, 2023 at 4:19 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > Said that there is a possibility that some of the slots which got
> > invalidated even on the previous checkpoint might get the same LSN as
> > the slot which got invalidated later if there is no activity between
> > these two checkpoints. So if we go with this approach then there is
> > some risk of migrating some of the slots which were already
> > invalidated even before the shutdown checkpoint.
> >
>
> I think even during the shutdown checkpoint, after writing shutdown
> checkpoint WAL, we can invalidate some slots that in theory are safe
> to migrate/copy because all the WAL for those slots would also have
> been sent. So, those would be similar to what we invalidate during the
> upgrade, no?

Thats correct

 If so, I think it is better to have the same behavior for
> invalidated slots irrespective of the time it gets invalidated. We can
> either give an error for such slots during the upgrade (which means
> disallow the upgrade) or simply ignore such slots during the upgrade.
> I would prefer ERROR but if we want to ignore such slots, we can
> probably inform the user in some way about ignored slots, so that she
> can later drop corresponding subscritions or recreate such slots and
> do the required sync-up to continue the replication.

Earlier I was thinking that ERRORing out is better so that the user
can take necessary action for the invalidated slots and then retry
upgrade.  But thinking again I could not find what are the advantages
of this because if we error out then also users need to restart the
old cluster again and have to drop the corresponding subscriptions
OTOH if we allow the upgrade by ignoring the slots then also the user
has to take similar actions on the new cluster?  So what's the
advantage of erroring out over upgrading?  I see a clear advantage of
upgrading is that the user wants to upgrade and that's successful
without reattempting.   If we say that if we error out and then there
are some option for user to salvage those invalidated slots and he can
somehow migrate those slot as well by retrying upgrade then it make
sense to error out and let user take some action on old cluster, but
if all he has to do is to drop the subscription or recreate the slot
in both the cases then letting the upgrade pass is better option at
least IMHO.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: persist logical slots to disk during shutdown checkpoint
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: persist logical slots to disk during shutdown checkpoint