Re: Handle infinite recursion in logical replication setup

On Tue, Jan 10, 2023 at 11:24 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>
> On 1/10/23 10:17 AM, Amit Kapila wrote:
> > On Tue, Jan 10, 2023 at 8:13 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>
> > One can use local or higher
> > for reducing the latency for COMMIT when synchronous replication is
> > used in the publisher. Won't using 'local' while creating subscription
> > would suffice the need to consistently replicate the data? I mean it
> > is equivalent to somebody using levels greater than local in case of
> > physical replication. I think in the case of physical replication, we
> > won't wait for standby to replicate to another node before sending a
> > response, so why to wait in the case of logical replication? If this
> > understanding is correct, then probably it is sufficient to support
> > 'local' for a subscription.
>
> I think this is a good explanation. We should incorporate some version
> of this into the docs, and add some clarity around the use of
> `synchronous_commit` option in `CREATE SUBSCRIPTION` in particular with
> the origin feature. I can make an attempt at this.
>

Okay, thanks!

> Perhaps another question: based on this, should we disallow setting
> values of `synchronous_commit` greater than `local` when using
> "origin=none"?
>

I think it should be done irrespective of the value of origin because
it can create a deadlock in those cases as well. I think one idea as
you suggest is to block levels higher than local and the other is to
make it behave like 'local' even if the level is higher than 'local'
which would be somewhat similar to our physical replication.

> That might be too strict, but maybe we should warn around
> the risk of deadlock either in the logs or in the docs.
>

Yeah, we can mention it in docs as well. We can probably document as
part of the docs work for this thread but it would be better to start
a separate thread to fix this behavior by either of the above two
approaches.

--
With Regards,
Amit Kapila.