Re: Skipping logical replication transactions on subscriber side

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Skipping logical replication transactions on subscriber side
Дата
Msg-id CAA4eK1+Ki_QibRd+sADk-a4C3dC8o-VtZifz9fQN_Z135FhrqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Skipping logical replication transactions on subscriber side  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Skipping logical replication transactions on subscriber side  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
On Mon, Jan 24, 2022 at 7:36 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 22.01.22 03:54, Amit Kapila wrote:
> > Won't we already do that for Alter Subscription command which means
> > nothing special needs to be done for this? However, it seems to me
> > that the idea we are trying to follow here is that as this option can
> > lead to data inconsistency, it is good to allow only superusers to
> > specify this option. The owner of the subscription can be changed to
> > non-superuser as well in which case I think it won't be a good idea to
> > allow this option. OTOH, if we think it is okay to allow such an
> > option to users that don't have superuser privilege then I think
> > allowing it to the owner of the subscription makes sense to me.
>
> I don't think this functionality allows a nonprivileged user to do
> anything they couldn't otherwise do.  You can create inconsistent data
> in the sense that you can choose not to apply certain replicated data.
>

I thought this will be the only primary way to skip applying certain
transactions. The other could be via pg_replication_origin_advance().
Or are you talking about the case where we skip applying update/delete
where the corresponding rows are not found?

I see the point that if we can allow the owner to skip applying
updates/deletes in certain cases then probably this should also be
okay. Kindly let us know if you have something else in mind as well?

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: 2022-01 Commitfest