Re: Column Filtering in Logical Replication
Amit Kapila <amit.kapila16@gmail.com>
On Thu, Apr 14, 2022 at 9:09 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Apr 14, 2022 at 8:32 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > The other part of the puzzle is the below check in the code:
> > > /*
> > > * If we reached the sync worker limit per subscription, just exit
> > > * silently as we might get here because of an otherwise harmless race
> > > * condition.
> > > */
> > > if (nsyncworkers >= max_sync_workers_per_subscription)
> > >
> > > It is not clear to me why this check is there, if this wouldn't be
> > > there, the user would have got either a WARNING to increase the
> > > max_logical_replication_workers or the apply worker would have been
> > > restarted. Do you have any idea about this?
> >
> > Yeah, I'm also puzzled with this check. It seems that this function
> > doesn't work well when the apply worker is not running and some
> > tablesync workers are running. I initially thought that the apply
> > worker calls to this function as many as tables that needs to be
> > synced, but it checks the max_sync_workers_per_subscription limit
> > before calling to logicalrep_worker_launch(). So I'm not really sure
> > we need this check.
> >
>
> I just hope that the original author Petr J. responds to this point. I
> have added him to this email. This will help us to find the best
> solution for this problem.
>
I did some more investigation for this code. It is added by commit [1]
and the patch that led to this commit is first time posted on -hackers
in email [2]. Now, neither the commit message nor the patch (comments)
gives much idea as to why this part of code is added but I think there
is some hint in the email [2]. In particular, read the paragraph in
the email [2] that has the lines: ".... and limiting sync workers per
subscription theoretically wasn't either (although I don't think it
could happen in practice).".
It seems that this check has been added to theoretically limit the
sync workers even though that can't happen because apply worker
ensures that before trying to launch the sync worker. Does this theory
make sense to me? If so, I think we can change the check as: "if
(OidIsValid(relid) && nsyncworkers >=
max_sync_workers_per_subscription)" in launcher.c. This will serve the
purpose of the original code and will solve the issue being discussed
here. I think we can even backpatch this. What do you think?
[1]
commit de4389712206d2686e09ad8d6dd112dc4b6c6d42
Author: Peter Eisentraut <peter_e@gmx.net>
Date: Wed Apr 26 10:43:04 2017 -0400
Fix various concurrency issues in logical replication worker launching
[2] - https://www.postgresql.org/message-id/fa387e24-0e26-c02d-ef16-7e46ada200dd%402ndquadrant.com
--
With Regards,
Amit Kapila.
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Explain about Column List feature.
- f98d07424523 16.0 landed
- 25996a82a446 15.0 landed
-
Doc: fix column list vs. replica identity rules.
- 376af686111e 16.0 landed
- ab3131880d8a 15.0 landed
-
Prohibit combining publications with different column lists.
- fd0b9dcebda7 15.0 cited
-
Fix the check to limit sync workers.
- be46985bed8a 10.21 landed
- a90de822e483 11.16 landed
- 59348fbdeb7b 12.11 landed
- 82d4a17a1750 13.7 landed
- c9dea58e2702 14.3 landed
- dd4ab6fd6528 15.0 landed
-
Wait for subscription to sync in t/031_column_list.sql
- 404f49338fef 15.0 landed
-
Move prattrs to the pg_publication_rel section in docs
- 41b00f8e601f 15.0 landed
-
Allow specifying column lists for logical replication
- 923def9a533a 15.0 landed
-
Fix row filters with multiple publications
- 5a079662256e 15.0 landed
-
Fix publish_as_relid with multiple publications
- 27fafee72d17 13.7 landed
- 677a1dc0ca0f 14.3 landed
- c91f71b9dc91 15.0 landed
-
Add some additional tests for row filters in logical replication.
- ceb57afd3ce1 15.0 cited
-
Add index on pg_publication_rel.prpubid
- 025b920a3d45 15.0 landed
-
Avoid using DefElemAction in AlterPublicationStmt
- 9623d8999603 15.0 landed
-
Small cleanups related to PUBLICATION framework code
- c9105dd3660f 15.0 landed
-
Add PublicationTable and PublicationRelInfo structs
- 0c6828fa987b 15.0 landed
-
Fix various concurrency issues in logical replication worker launching
- de4389712206 10.0 cited