Causes for pg_class locks except DROP TABLE

Question

I do experience the following situation on a PostgreSQL 11:

1. A transaction with unknown statements creates an ACCESS SHARE lock on pg_class.
2. Another connection wants to execute DROP TABLE which causes an ACCESS EXCLUSIVE lock on pg_class. This operation is blocked because operation #1 still holds the lock.
3. Following that any new connection to the DB is waiting forever, because it needs to access pg_class as well.

The only way to proceed is to either kill operation #1 or #2.

While I can reproduce the situation with manual locking the tables, I do not find an explanation what causes the pg_class lock on operation #1. That is, pg_stats_activity only shows a SELECT as current query which is idle in transaction. I suspect this not being the statement creating the lock, however.

Thus, any input on what could cause ACCESS SHARE locks on pg_class except DROP TABLE is highly appreciated.

Update atm it is also unclear why DROP TABLE wants to lock pg_class.

Answer 1

The situation is caused by a long-running transaction which does a SELECT on pg_class first. This causes the ACCESS SHARE lock.

Typically, DROP TABLE does not cause an ACCESS EXCLUSIVE lock, but in that case there is a PG extension loaded which uses more restrictive locking.

Solution for the current situation is to move the SELECT on pg_class out of the long-running transaction.