As commented by a_horse_with_no_name, what you are seeing in pgadmin are regular locks, not deadlocks.
From the Postgres documentation:
PostgreSQL provides various lock modes to control concurrent access to data in tables. These modes can be used for application-controlled locking in situations where MVCC does not give the desired behavior. Also, most PostgreSQL commands automatically acquire locks of appropriate modes to ensure that referenced tables are not dropped or modified in incompatible ways while the command executes.
The screen in pgadmin is probably based on the pg_lock
system view.
Locks happen in the normal process of any database. You don't want to kill sessions that generate locks on a regular basis, because that can affect your application and your database in various ways. Instead you probably want to identify (maybe using the pg_lock
view), analyze and optimize the queries which are causing issues.
When it comes to the concept of deadlock: that's a specific, abnormal situation that may happen when using lock, where two sessions are mutually waiting for the other. They usually indicate issues in the application logic.
Most RDBMS automatically identify and resolve such blocking situation, and Postgres is no exception:
PostgreSQL automatically detects deadlock situations and resolves them by aborting one of the transactions involved, allowing the other(s) to complete. (Exactly which transaction will be aborted is difficult to predict and should not be relied upon.)