Re: Handle infinite recursion in logical replication setup
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: vignesh C <vignesh21@gmail.com>,
"shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>,
"houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, Dilip Kumar <dilipbalaut@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2023-01-11T02:16:42Z
Lists: pgsql-hackers
On Tue, Jan 10, 2023 at 11:24 PM Jonathan S. Katz <jkatz@postgresql.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@postgresql.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.
Commits
-
Improved CREATE SUBSCRIPTION message for clarity
- 1e7ca1189ccc 17.0 landed
- 842b65905046 16.0 landed
-
Fix the test case introduced by commit 8756930190.
- 032465157347 16.0 landed
-
Raise a warning if there is a possibility of data from multiple origins.
- 875693019053 16.0 landed
-
Add wait_for_subscription_sync for TAP tests.
- 0c20dd33db16 16.0 cited
-
Bump catversion for commit d8cd0c6c95c0120168df93aae095df4e0682a08a.
- 5f858dd3bebd 16.0 cited
-
Allow users to skip logical replication of data having origin.
- 366283961ac0 16.0 landed
-
Improve two comments related to a boolean DefElem's value
- 8445f5a21d40 16.0 cited
-
doc: Fix man page whitespace issues
- d7ab2a9a3c0a 15.0 cited