From: | Ajin Cherian <itsajin(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Single transaction in the tablesync worker? |
Date: | 2021-02-03 01:28:33 |
Message-ID: | CAFPTHDb9bPHGW8bX7w2+RJvn=Ha8a2Uoj1A=Az66PNSB52871w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 3, 2021 at 12:24 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2021-02-03 02:11:11 | RE: libpq debug log |
Previous Message | tsunakawa.takay@fujitsu.com | 2021-02-03 01:26:41 | RE: libpq debug log |