Re: Single transaction in the tablesync worker?
Ajin Cherian <itsajin@gmail.com>
From: Ajin Cherian <itsajin@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-03T01:28:33Z
Lists: pgsql-hackers
On Wed, Feb 3, 2021 at 12:24 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > The problem here is that we are allowing to drop the table when table > synchronization is still in progress and then we don't have any way to > know the corresponding slot or origin. I think we can try to drop the > slot and origin as well but that is not a good idea because slots once > dropped won't be rolled back. So, I have added a fix to disallow the > drop of the table when table synchronization is still in progress. > Apart from that, I have fixed comments raised by Peter as discussed > above and made some additional changes in comments, code (code changes > are cosmetic), and docs. > > Let me know if the issue reported is fixed or not? Yes, the issue is fixed, now the table drop results in an error. postgres=# drop table tab_rep ; ERROR: could not drop relation mapping for subscription "tap_sub" DETAIL: Table synchronization for relation "tab_rep" is in progress and is in state "f". HINT: Use ALTER SUBSCRIPTION ... ENABLE to enable subscription if not already enabled or use DROP SUBSCRIPTION ... to drop the subscription. regards, Ajin Cherian 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