Re: Single transaction in the tablesync worker?
Peter Smith <smithpb2250@gmail.com>
From: Peter Smith <smithpb2250@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Petr Jelinek <petr.jelinek@enterprisedb.com>,
Petr Jelinek <petr@2ndquadrant.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Ajin Cherian <itsajin@gmail.com>, Craig Ringer <craig.ringer@enterprisedb.com>
Date: 2020-12-07T03:44:20Z
Lists: pgsql-hackers
Hi, I wanted to float another idea to solve these tablesync/apply worker problems. This idea may or may not have merit. Please consider it. ~ Basically, I was wondering why can't the "tablesync" worker just gather messages in a similar way to how the current streaming feature gathers messages into a "changes" file, so that they can be replayed later. e.g. Imagine if A) The "tablesync" worker (after the COPY) does not ever apply any of the incoming messages, but instead it just gobbles them into a "changes" file until it decides it has reached SYNCDONE state and exits. B) Then, when the "apply" worker proceeds, if it detects the existence of the "changes" file it will replay/apply_dispatch all those gobbled messages before just continuing as normal. So - IIUC this kind of replay is like how the current code stream commit applies the streamed "changes" file. - "tablesync" worker would only be doing table sync (COPY) as its name suggests. Any detected "changes" are recorded and left for the "apply" worker to handle. - "tablesync" worker would just operate in single tx with a temporary slot as per current code - Then the "apply" worker would be the *only* worker that actually applies anything. (as its name suggests) Thoughts? --- Kind Regards, Peter Smith. Fujitsu Australia
Commits
-
Fix relcache reference leak introduced by ce0fdbfe97.
- 8a4f9522d0c7 14.0 landed
-
Fix Subscription test added by commit ce0fdbfe97.
- c8b21b037814 14.0 landed
-
Allow multiple xacts during table sync in logical replication.
- ce0fdbfe9722 14.0 landed
-
Logical replication support for initial data copy
- 7c4f52409a8c 10.0 cited