Activity waits

• 1: Activity: ArchiverMain
• 2: Activity: AutovacuumMain
• 3: Activity: BgwriterHibernate
• 4: Activity: BgwriterMain
• 5: Activity: CheckpointerMain
• 6: Activity: CheckpointerShutdown
• 7: Activity: IoWorkerMain
• 8: Activity: LogicalApplyMain
• 9: Activity: LogicalLauncherMain
• 10: Activity: LogicalParallelApplyMain
• 11: Activity: PgStatMain
• 12: Activity: RecoveryWalStream
• 13: Activity: ReplicationSlotsyncMain
• 14: Activity: ReplicationSlotsyncShutdown
• 15: Activity: SysloggerMain
• 16: Activity: WalReceiverMain
• 17: Activity: WalSenderMain
• 18: Activity: WalSummarizerWal
• 19: Activity: WalWriterMain

1 - Activity: ArchiverMain

Official description

Waiting in main loop of archiver process

Trigger mechanism

WAIT_EVENT_ARCHIVER_MAIN at src/backend/postmaster/pgarch.c:362 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:54. The instrumented operation is: Waiting in main loop of archiver process. The ArchiverMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'ArchiverMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'ArchiverMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/postmaster/pgarch.c:362 — WAIT_EVENT_ARCHIVER_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:54 — ARCHIVER_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

2 - Activity: AutovacuumMain

Official description

Waiting in main loop of autovacuum launcher process

Earlier names: Activity/AutoVacuumMain (PG 13-16)

Trigger mechanism

WAIT_EVENT_AUTOVACUUM_MAIN at src/backend/postmaster/autovacuum.c:667 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:216. The instrumented operation is: Waiting in main loop of autovacuum launcher process. The AutovacuumMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'AutovacuumMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'AutovacuumMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 16.15 · src/backend/postmaster/autovacuum.c:667 — WAIT_EVENT_AUTOVACUUM_MAIN
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:216 — AutoVacuumMain
• PostgreSQL 18.6 · src/backend/postmaster/autovacuum.c:595 — WAIT_EVENT_AUTOVACUUM_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:55 — AUTOVACUUM_MAIN

Related controls and signals

• GUCs: [guc:autovacuum_naptime]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:oldest_transaction_age]

3 - Activity: BgwriterHibernate

Official description

Waiting in background writer process, hibernating

Earlier names: Activity/BgWriterHibernate (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWRITER_HIBERNATE at src/backend/postmaster/bgwriter.c:339 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:219. The instrumented operation is: Waiting in background writer process, hibernating. The BgwriterHibernate background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'BgwriterHibernate'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'BgwriterHibernate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 16.15 · src/backend/postmaster/bgwriter.c:339 — WAIT_EVENT_BGWRITER_HIBERNATE
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:219 — BgWriterHibernate
• PostgreSQL 18.6 · src/backend/postmaster/bgwriter.c:337 — WAIT_EVENT_BGWRITER_HIBERNATE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:56 — BGWRITER_HIBERNATE

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

4 - Activity: BgwriterMain

Official description

Waiting in main loop of background writer process

Earlier names: Activity/BgWriterMain (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWRITER_MAIN at src/backend/postmaster/bgwriter.c:311 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:222. The instrumented operation is: Waiting in main loop of background writer process. The BgwriterMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'BgwriterMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'BgwriterMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 16.15 · src/backend/postmaster/bgwriter.c:311 — WAIT_EVENT_BGWRITER_MAIN
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:222 — BgWriterMain
• PostgreSQL 18.6 · src/backend/postmaster/bgwriter.c:309 — WAIT_EVENT_BGWRITER_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:57 — BGWRITER_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

5 - Activity: CheckpointerMain

Official description

Waiting in main loop of checkpointer process

Trigger mechanism

WAIT_EVENT_CHECKPOINTER_MAIN at src/backend/postmaster/checkpointer.c:583 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:58. The instrumented operation is: Waiting in main loop of checkpointer process. The CheckpointerMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'CheckpointerMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'CheckpointerMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/postmaster/checkpointer.c:583 — WAIT_EVENT_CHECKPOINTER_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:58 — CHECKPOINTER_MAIN

Related controls and signals

• GUCs: [guc:checkpoint_timeout] · [guc:max_wal_size]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:checkpoint_time]

6 - Activity: CheckpointerShutdown

Official description

Waiting for checkpointer process to be terminated

Trigger mechanism

WAIT_EVENT_CHECKPOINTER_SHUTDOWN at src/backend/postmaster/checkpointer.c:631 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:59. The instrumented operation is: Waiting for checkpointer process to be terminated. The CheckpointerShutdown background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'CheckpointerShutdown'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'CheckpointerShutdown'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/postmaster/checkpointer.c:631 — WAIT_EVENT_CHECKPOINTER_SHUTDOWN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:59 — CHECKPOINTER_SHUTDOWN

Related controls and signals

• GUCs: [guc:checkpoint_timeout] · [guc:max_wal_size]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:checkpoint_time]

7 - Activity: IoWorkerMain

Official description

Waiting in main loop of IO Worker process

Trigger mechanism

WAIT_EVENT_IO_WORKER_MAIN at src/backend/storage/aio/method_worker.c:573 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:60. The instrumented operation is: Waiting in main loop of IO Worker process. The IoWorkerMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'IoWorkerMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'IoWorkerMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/storage/aio/method_worker.c:573 — WAIT_EVENT_IO_WORKER_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:60 — IO_WORKER_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

8 - Activity: LogicalApplyMain

Official description

Waiting in main loop of logical replication apply process

Trigger mechanism

WAIT_EVENT_LOGICAL_APPLY_MAIN at src/backend/replication/logical/worker.c:3766 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:61. The instrumented operation is: Waiting in main loop of logical replication apply process. The LogicalApplyMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'LogicalApplyMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'LogicalApplyMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/replication/logical/worker.c:3766 — WAIT_EVENT_LOGICAL_APPLY_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:61 — LOGICAL_APPLY_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

9 - Activity: LogicalLauncherMain

Official description

Waiting in main loop of logical replication launcher process

Trigger mechanism

WAIT_EVENT_LOGICAL_LAUNCHER_MAIN at src/backend/replication/logical/launcher.c:1242 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:62. The instrumented operation is: Waiting in main loop of logical replication launcher process. The LogicalLauncherMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'LogicalLauncherMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'LogicalLauncherMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/replication/logical/launcher.c:1242 — WAIT_EVENT_LOGICAL_LAUNCHER_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:62 — LOGICAL_LAUNCHER_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

10 - Activity: LogicalParallelApplyMain

Official description

Waiting in main loop of logical replication parallel apply process

Trigger mechanism

WAIT_EVENT_LOGICAL_PARALLEL_APPLY_MAIN at src/backend/replication/logical/applyparallelworker.c:810 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:63. The instrumented operation is: Waiting in main loop of logical replication parallel apply process. The LogicalParallelApplyMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'LogicalParallelApplyMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'LogicalParallelApplyMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/replication/logical/applyparallelworker.c:810 — WAIT_EVENT_LOGICAL_PARALLEL_APPLY_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:63 — LOGICAL_PARALLEL_APPLY_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

11 - Activity: PgStatMain

Official description

Waiting in main loop of statistics collector process.

Trigger mechanism

WAIT_EVENT_PGSTAT_MAIN at src/backend/postmaster/pgstat.c:3425 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:234. The instrumented operation is: Waiting in main loop of statistics collector process. The PgStatMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'PgStatMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'PgStatMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 14.24 · src/backend/postmaster/pgstat.c:3425 — WAIT_EVENT_PGSTAT_MAIN
• PostgreSQL 14.24 · src/backend/utils/activity/wait_event.c:234 — PgStatMain

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

12 - Activity: RecoveryWalStream

Official description

Waiting in main loop of startup process for WAL to arrive, during streaming recovery

Trigger mechanism

WAIT_EVENT_RECOVERY_WAL_STREAM at src/backend/access/transam/xlogrecovery.c:4038 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:64. The instrumented operation is: Waiting in main loop of startup process for WAL to arrive, during streaming recovery. The RecoveryWalStream background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'RecoveryWalStream'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'RecoveryWalStream'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlogrecovery.c:4038 — WAIT_EVENT_RECOVERY_WAL_STREAM
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:64 — RECOVERY_WAL_STREAM

Related controls and signals

• GUCs: [guc:wal_buffers] · [guc:synchronous_commit]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time]

13 - Activity: ReplicationSlotsyncMain

Official description

Waiting in main loop of slot sync worker

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOTSYNC_MAIN at src/backend/replication/logical/slotsync.c:1369 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:65. The instrumented operation is: Waiting in main loop of slot sync worker. The ReplicationSlotsyncMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'ReplicationSlotsyncMain'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Activity'
  AND a.wait_event = 'ReplicationSlotsyncMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Match the row to backend_type.
2. Inspect the process-specific backlog and last-progress timestamp.
3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

• PostgreSQL 18.6 · src/backend/replication/logical/slotsync.c:1369 — WAIT_EVENT_REPLICATION_SLOTSYNC_MAIN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:65 — REPLICATION_SLOTSYNC_MAIN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

14 - Activity: ReplicationSlotsyncShutdown

Official description

Waiting for slot sync worker to shut down

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOTSYNC_SHUTDOWN at src/backend/replication/logical/slotsync.c:1732 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:66. The instrumented operation is: Waiting for slot sync worker to shut down. The ReplicationSlotsyncShutdown background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

• Normal: This is normally expected idleness for the matching background process.
• Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Activity'
  AND wait_event = 'ReplicationSlotsyncShutdown'
ORDER BY query_age DESC NULLS LAST;