3

I'm running Postgres 12 on AWS RDS and monitoring it with 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 startup process?
  • 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 process also indicates that this process shouldn't exist after postgres starts up. Should I consider killing the session?
Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
3
  • So this process holding locks for such a long time and queries being blocked might mean that the replication became very slow. Sometimes canceling blocked queries actually releases the locks quickly afterward. Anyway thanks for the answer, this unblocks my search effort as it's pretty tough googling postgres startup process. You usually get links related to turning on Postgres.
    – Spidey
    Commented Mar 1, 2023 at 14:06
  • 1
    The only locks that the startup process should hold are ACCESS EXCLUSIVE locks. They can be caused by statements like TRUNCATE or ALTER TABLE on the primary, or by vacuum truncation.
    – Laurenz Albe
    Commented Mar 1, 2023 at 14:29
  • Thanks Laurenz for your proper and concise answer
    – Adam Mulla
    Commented Aug 25 at 6:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.