Amit, Zhijie, thank you for your replies!
> On 2 Aug 2023, at 10:20, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> Does this mean that Drop Database is waiting for walsender instead of
> tablesync worker? Can you show the pg_stat_activity row of backend for
> which the Drop Database command is waiting?
Yes, there were no active table syncs.
Unfortunately, I do not have pg_stat_activity: the cluster was deleted amidst investigation session.
> On 2 Aug 2023, at 11:12, Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
>
> I think it would be better to get the whole info of pg_stat_activity when DROP
> database hangs. And the log is also needed as it may include log like "still
> waiting for backend with PID xxx to ...".
There are no logs: the cluster was operating in managed service. "DROP DATABASE" worker was operating with log level
ERROR.
> Besides, you mentioned there were inactive slots, but just to confirm, is there
> the logical replication running(active) in your environment ? If yes, it would be better
> to collect the bt of the logical replication workers if exists. This is to
> check if the hang is related to the logical replication or not.
The slots for logical replication were not from Postgres consumers. And receiving system as not running at all, so
there'sno relevant logs.
BTW there were 2 active slots of physical replication.
Thank you!
Best regards, Andrey Borodin.
