Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION

Поиск
Список
Период
Сортировка
On Fri, Aug 6, 2021 at 9:57 PM Japin Li <japinli@hotmail.com> wrote:
>
> >
> > Hmm yes, it cannot cover all cases. I had somehow misunderstood that
> > the subscriber knows which relations are associated with which
> > publications. Given that the subscriber doesn’t know which relations
> > are associated with which publications (and the set of subscribed
> > relations on the subscriber becomes out of date once the publication
> > is updated), I think it's impossible to achieve that DROP PUBLICATION
> > drops relations that are associated with only the publication being
> > dropped.
> >
> >> Do we have better ideas to fix or shall we just
> >> say that we will refresh based on whatever current set of relations
> >> are present in publication to be dropped?
> >
> > I don't have better ideas. It seems to me that it's prudent that we
> > accept the approach in v3 patch and refresh all publications in DROP
> > PUBLICATION cases.
> >
>
> Maybe refreshing all publications in PUBLICATION cases is simple way to
> fix the problem.
>

Do you mean to say that do it for both Add and Drop or just for Drop?
Actually, doing it both will make the behavior consistent but doing it
just for Drop might be preferable by some users. I think it is better
to be consistent here but I am fine if you and others feel it is
better to refresh all publications only in Drop case.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Alias collision in `refresh materialized view concurrently`
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Diagnostic comment in LogicalIncreaseXminForSlot