--- title: All Your GUCs in a Row: log_replication_commands | daily.dev description: log_replication_commands is the replication-protocol equivalent of log_statement=all — it logs the special commands (IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT,... canonical: https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: All Your GUCs in a Row: log_replication_commands | daily.dev og:description: log_replication_commands is the replication-protocol equivalent of log_statement=all — it logs the special commands (IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT,... og:url: https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv og:image: https://api.daily.dev/og/posts/1aMGZ3VFV.png og:image:alt: All Your GUCs in a Row: log_replication_commands og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # All Your GUCs in a Row: log_replication_commands **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 3 min read · 0 upvotes · 0 comments ## Summary log_replication_commands is the replication-protocol equivalent of log_statement=all — it logs the special commands (IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT, START_REPLICATION, BASE_BACKUP, DROP_REPLICATION_SLOT) that walsenders receive but log_statement never sees. Off by default since PostgreSQL 9.5 (silently logged at DEBUG1 instead), it requires superuser and a reload to enable via postgresql.conf. It reveals what standbys, backup tools, and logical subscribers actually requested, including publication names and protocol versions for logical subscriptions, and timestamps for pg_basebackup runs. PostgreSQL 17 extended it to log slot acquire/release events, useful for spotting standbys reconnecting repeatedly. Cost is negligible except for clients stuck in reconnect loops, which is itself diagnostic. Two quirks: each line is duplicated with a STATEMENT: repeat, and ordinary SQL on logical replication connections is still logged by log_statement, not this parameter. The author recommends always turning it on. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What does the PostgreSQL log_replication_commands parameter actually log? It logs the replication-protocol commands a walsender receives, such as IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT, START_REPLICATION, BASE_BACKUP, and DROP_REPLICATION_SLOT, at LOG level as 'received replication command: ...'. These commands are invisible to log_statement. It is off by default (logged at DEBUG1 instead when disabled), requires superuser privileges to change, and has existed since PostgreSQL 9.5. _Track PostgreSQL configuration parameters like this one on daily.dev to tune replication visibility with confidence._ ### What new replication logging did PostgreSQL 17 add? PostgreSQL 17 added logging whenever a walsender acquires or releases a replication slot, printing lines like 'acquired physical replication slot "phys1"' or 'released logical replication slot "sub"'. This is gated by the same log_replication_commands parameter. Combined with the new inactive_since column in pg_replication_slots, it lets administrators see the history of slot usage, such as a standby reconnecting many times. _Follow PostgreSQL version-specific replication changes on daily.dev when planning an upgrade or debugging slot behavior._ ### Why does ordinary SQL on a logical replication connection sometimes not appear under log_replication_commands? Ordinary SQL sent over a logical replication connection, which walsenders in that mode accept and which subscriber table-sync workers use, is logged by log_statement instead of log_replication_commands. Since PostgreSQL 10, the two logging mechanisms no longer both log the same statement, so administrators must check log_statement for that SQL rather than expecting it in the replication command log. _Compare PostgreSQL logging parameter behavior on daily.dev before debugging a logical replication issue._ ## Similar posts on daily.dev - [All Your GUCs in a Row: hot\_standby](https://daily.dev/posts/all-your-gucs-in-a-row-hot-standby-wgsmgbrpp) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: log\_connections, log\_disconnections, and log\_hostname](https://daily.dev/posts/all-your-gucs-in-a-row-log-connections-log-disconnections-and-log-hostname-othkylola) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: log\_min\_duration\_sample, log\_statement\_sample\_rate, and log\_transaction\_sample\_rate](https://daily.dev/posts/all-your-gucs-in-a-row-log-min-duration-sample-log-statement-sample-rate-and-log-transaction-samp-q1podf82k) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: idle\_replication\_slot\_timeout](https://daily.dev/posts/all-your-gucs-in-a-row-idle-replication-slot-timeout-5ezg0va9j) · Planet PostgreSQL · 0 upvotes · 1 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"All Your GUCs in a Row: log_replication_commands","url":"https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv"},"datePublished":"2026-09-03T01:01:12.803Z","dateModified":"2026-09-03T04:18:37.808Z","description":"log_replication_commands is the replication-protocol equivalent of log_statement=all — it logs the special commands (IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/174a79d1228a839092bba8ab8799a5cb?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/174a79d1228a839092bba8ab8799a5cb?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"All Your GUCs in a Row: log_replication_commands"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-log-replication-commands-1amgz3vfv#faq","mainEntity":[{"@type":"Question","name":"What does the PostgreSQL log_replication_commands parameter actually log?","acceptedAnswer":{"@type":"Answer","text":"It logs the replication-protocol commands a walsender receives, such as IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT, START_REPLICATION, BASE_BACKUP, and DROP_REPLICATION_SLOT, at LOG level as 'received replication command: ...'. These commands are invisible to log_statement. It is off by default (logged at DEBUG1 instead when disabled), requires superuser privileges to change, and has existed since PostgreSQL 9.5. Track PostgreSQL configuration parameters like this one on daily.dev to tune replication visibility with confidence."}},{"@type":"Question","name":"What new replication logging did PostgreSQL 17 add?","acceptedAnswer":{"@type":"Answer","text":"PostgreSQL 17 added logging whenever a walsender acquires or releases a replication slot, printing lines like 'acquired physical replication slot \"phys1\"' or 'released logical replication slot \"sub\"'. This is gated by the same log_replication_commands parameter. Combined with the new inactive_since column in pg_replication_slots, it lets administrators see the history of slot usage, such as a standby reconnecting many times. Follow PostgreSQL version-specific replication changes on daily.dev when planning an upgrade or debugging slot behavior."}},{"@type":"Question","name":"Why does ordinary SQL on a logical replication connection sometimes not appear under log_replication_commands?","acceptedAnswer":{"@type":"Answer","text":"Ordinary SQL sent over a logical replication connection, which walsenders in that mode accept and which subscriber table-sync workers use, is logged by log_statement instead of log_replication_commands. Since PostgreSQL 10, the two logging mechanisms no longer both log the same statement, so administrators must check log_statement for that SQL rather than expecting it in the replication command log. Compare PostgreSQL logging parameter behavior on daily.dev before debugging a logical replication issue."}}]} ```