Re: Column Filtering in Logical Replication
Tomas Vondra <tomas.vondra@enterprisedb.com>
On 3/29/22 12:00, Amit Kapila wrote: > On Sun, Mar 20, 2022 at 4:53 PM Tomas Vondra > <tomas.vondra@enterprisedb.com> wrote: >> >> On 3/20/22 07:23, Amit Kapila wrote: >>> On Sun, Mar 20, 2022 at 8:41 AM Amit Kapila <amit.kapila16@gmail.com> wrote: >>>> >>>> On Fri, Mar 18, 2022 at 10:42 PM Tomas Vondra >>>> <tomas.vondra@enterprisedb.com> wrote: >>>> >>>>> So the question is why those two sync workers never complete - I guess >>>>> there's some sort of lock wait (deadlock?) or infinite loop. >>>>> >>>> >>>> It would be a bit tricky to reproduce this even if the above theory is >>>> correct but I'll try it today or tomorrow. >>>> >>> >>> I am able to reproduce it with the help of a debugger. Firstly, I have >>> added the LOG message and some While (true) loops to debug sync and >>> apply workers. Test setup >>> >>> Node-1: >>> create table t1(c1); >>> create table t2(c1); >>> insert into t1 values(1); >>> create publication pub1 for table t1; >>> create publication pu2; >>> >>> Node-2: >>> change max_sync_workers_per_subscription to 1 in potgresql.conf >>> create table t1(c1); >>> create table t2(c1); >>> create subscription sub1 connection 'dbname = postgres' publication pub1; >>> >>> Till this point, just allow debuggers in both workers just continue. >>> >>> Node-1: >>> alter publication pub1 add table t2; >>> insert into t1 values(2); >>> >>> Here, we have to debug the apply worker such that when it tries to >>> apply the insert, stop the debugger in function apply_handle_insert() >>> after doing begin_replication_step(). >>> >>> Node-2: >>> alter subscription sub1 set pub1, pub2; >>> >>> Now, continue the debugger of apply worker, it should first start the >>> sync worker and then exit because of parameter change. All of these >>> debugging steps are to just ensure the point that it should first >>> start the sync worker and then exit. After this point, table sync >>> worker never finishes and log is filled with messages: "reached >>> max_sync_workers_per_subscription limit" (a newly added message by me >>> in the attached debug patch). >>> >>> Now, it is not completely clear to me how exactly '013_partition.pl' >>> leads to this situation but there is a possibility based on the LOGs >>> it shows. >>> >> >> Thanks, I'll take a look later. >> > > This is still failing [1][2]. > > [1] - https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican&dt=2022-03-28%2005%3A16%3A53 > [2] - https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2022-03-24%2013%3A13%3A08 > AFAICS we've concluded this is a pre-existing issue, not something introduced by a recently committed patch, and I don't think there's any proposal how to fix that. So I've put that on the back burner until after the current CF. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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