| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Subscription statistics are not dropped at DROP SUBSCRIPTION in some cases |
| Date: | 2023-05-09 00:07:21 |
| Message-ID: | 20230509000721.GA2515086@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 08, 2023 at 04:23:15PM +0900, Masahiko Sawada wrote:
> We call pgstat_drop_subscription() at the end of DropSubscription()
> but we could leave from this function earlier e.g. when no slot is
> associated with the subscription. In this case, the statistics entry
> for the subscription remains. To fix it, I think we need to call it
> earlier, just after removing the catalog tuple. There is a chance the
> transaction dropping the subscription fails due to network error etc
> but we don't need to worry about it as reporting the subscription drop
> is transactional.
Looks reasonable to me. IIUC calling pgstat_drop_subscription() earlier
makes no real difference (besides avoiding this bug) because it is uѕing
pgstat_drop_transactional() behind the scenes.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2023-05-09 02:19:20 | Re: Perform streaming logical transactions by background workers and parallel apply |
| Previous Message | Nathan Bossart | 2023-05-08 23:40:54 | Re: Cleaning up array_in() |