patternsqlMinor
Postgres RDS session with backend type "startup", empty activity and no query holds locks on tables
Viewed 0 times
backendtablespostgreswithqueryemptytypeactivitysessionand
Problem
I'm running Postgres 12 on AWS RDS and monitoring it with
I have a weird session with not much info, only:
My questions are:
pgAdmin. This is a read-only replica of the production database.I have a weird session with not much info, only:
backend_type = startup, PID, and backend_start. All other columns in pg_stat_activity are null, also no user or database info (looking at pgAdmin session dashboard). This session will sometimes hold a few exclusive locks on a particular view and maybe some tables. The queries that get blocked by these locks aren't critical so canceling them is a temporary measure but it's still annoying to deal with because it can trigger replica lags. After some time (a week?) the locks are released until they're created again. The session has been running for a few months now.My questions are:
- Did anyone come across this
startupprocess?
- Can anyone recommend tables or commands for psql I can run to try getting additional info for this PID? I mostly checked
pg_stat_activity.
- Random searching for
postgres startup processalso indicates that this process shouldn't exist after postgres starts up. Should I consider killing the session?
Solution
You can find this mysterious “startup process” defined in the glossary of the documentation:
An auxiliary process that replays WAL during crash recovery and in a physical replica.
Yes, the name is kind of weird, and there were considerations to change it, but this process is replaying the transaction log streamed from the primary server to the data files. The name comes from crash recovery and archive recovery: there, WAL replay only happens until recovery is complete, then normal operation is resumed. With streaming replication, you remain in recovery mode all the time, so the standby is “starting up” all the while until you promote it.
An auxiliary process that replays WAL during crash recovery and in a physical replica.
Yes, the name is kind of weird, and there were considerations to change it, but this process is replaying the transaction log streamed from the primary server to the data files. The name comes from crash recovery and archive recovery: there, WAL replay only happens until recovery is complete, then normal operation is resumed. With streaming replication, you remain in recovery mode all the time, so the standby is “starting up” all the while until you promote it.
Context
StackExchange Database Administrators Q#324180, answer score: 2
Revisions (0)
No revisions yet.