Re: Handle infinite recursion in logical replication setup

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Handle infinite recursion in logical replication setup
Дата
Msg-id CAA4eK1+ey5Jmf5AXRc5XGLuLxMD7YdyxNN2B7AoX7r+-xR1m=w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Handle infinite recursion in logical replication setup  (vignesh C <vignesh21@gmail.com>)
Ответы Re: Handle infinite recursion in logical replication setup  (vignesh C <vignesh21@gmail.com>)
Список pgsql-hackers
On Tue, Jul 12, 2022 at 8:43 AM vignesh C <vignesh21@gmail.com> wrote:
>
> On Mon, Jul 11, 2022 at 9:11 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > Here are my review comments for the v30* patches:
> >
> > ========
> > v30-0001
> > ========
> >
> > 1.1 <general>
> >
> > I was wondering if it is better to implement a new defGetOrigin method
> > now instead of just using the defGetString to process the 'origin',
> > since you may need to do that in future anyway if the 'origin' name is
> > planned to become specifiable by the user. OTOH maybe you prefer to
> > change this code later when the time comes. I am not sure what way is
> > best.
>
> I preferred to do that change when the feature is getting extended.
>

+1.

*
+$node_C->safe_psql(
+     'postgres', "
+        DELETE FROM tab");
+$node_B->safe_psql(
+     'postgres', "
+        DELETE FROM tab where a = 32");
+
+$node_A->wait_for_catchup($subname_BA);
+$node_B->wait_for_catchup($subname_AB);

Here, don't we need to use node_C instead of node_A for waiting as we
have performed an operation on node_C?

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: DropRelFileLocatorBuffers
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [PATCH] New [relation] option engine