9/17/2020 PostgreSQL: Documentation: 12: 48.2.

Logical Decoding Concepts

17th September 2020: PostgreSQL 13 RC 1 Released!

Documentation → PostgreSQL 12
Search the documentation for... 
Supported Versions: Current (12) / 11 / 10 / 9.6 / 9.5
Development Versions: 13 / devel
Unsupported versions: 9.4

48.2. Logical Decoding Concepts

Prev  Up Chapter 48. Logical Decoding Home  Next

48.2. Logical Decoding Concepts

48.2.1. Logical Decoding
48.2.2. Replication Slots
48.2.3. Output Plugins
48.2.4. Exported Snapshots

48.2.1. Logical Decoding
Logical decoding is the process of extracting all persistent changes to a database's tables into a coherent, easy to understand format
which can be interpreted without detailed knowledge of the database's internal state.

In PostgreSQL, logical decoding is implemented by decoding the contents of the write-ahead log, which describe changes on a storage
level, into an application-speci c form such as a stream of tuples or SQL statements.

48.2.2. Replication Slots
In the context of logical replication, a slot represents a stream of changes that can be replayed to a client in the order they were made
on the origin server. Each slot streams a sequence of changes from a single database.

Note
PostgreSQL also has streaming replication slots (see Section 26.2.5), but they are used
somewhat di erently there.

A replication slot has an identi er that is unique across all databases in a PostgreSQL cluster. Slots persist independently of the
connection using them and are crash-safe.

A logical slot will emit each change just once in normal operation. The current position of each slot is persisted only at checkpoint, so
in the case of a crash the slot may return to an earlier LSN, which will then cause recent changes to be resent when the server
restarts. Logical decoding clients are responsible for avoiding ill e ects from handling the same message more than once. Clients may
wish to record the last LSN they saw when decoding and skip over any repeated data or (when using the replication protocol) request
that decoding start from that LSN rather than letting the server determine the start point. The Replication Progress Tracking feature is
designed for this purpose, refer to replication origins.

Multiple independent slots may exist for a single database. Each slot has its own state, allowing di erent consumers to receive
changes from di erent points in the database change stream. For most applications, a separate slot will be required for each
consumer.

A logical replication slot knows nothing about the state of the receiver(s). It's even possible to have multiple di erent receivers using
the same slot at di erent times; they'll just get the changes following on from when the last receiver stopped consuming them. Only
one receiver may consume changes from a slot at any given time.

Caution
Replication slots persist across crashes and know nothing about the state of their
consumer(s). They will prevent removal of required resources even when there is no
connection using them. This consumes storage because neither required WAL nor
required rows from the system catalogs can be removed by VACUUM as long as they are
required by a replication slot. In extreme cases this could cause the database to shut
down to prevent transaction ID wraparound (see Section 24.1.5). So if a slot is no longer
required it should be dropped.

48.2.3. Output Plugins

https://www.postgresql.org/docs/12/logicaldecoding-explanation.html 1/2
9/17/2020 PostgreSQL: Documentation: 12: 48.2. Logical Decoding Concepts

Output plugins transform the data from the write-ahead log's internal representation into the format the consumer of a replication
slot desires.

48.2.4. Exported Snapshots
When a new replication slot is created using the streaming replication interface (see CREATE_REPLICATION_SLOT), a snapshot is
exported (see Section 9.26.5), which will show exactly the state of the database after which all changes will be included in the change
stream. This can be used to create a new replica by using SET TRANSACTION SNAPSHOT to read the state of the database at the
moment the slot was created. This transaction can then be used to dump the database's state at that point in time, which afterwards
can be updated using the slot's contents without losing any changes.

Creation of a snapshot is not always possible. In particular, it will fail when connected to a hot standby. Applications that do not
require snapshot export may suppress it with the NOEXPORT_SNAPSHOT option.

Prev  Up  Next
48.1. Logical Decoding Examples  Home  48.3. Streaming Replication Protocol Interface

Submit correction  
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or
requires further clari cation, please use this form to report a documentation issue.

Privacy Policy | Code of Conduct | About PostgreSQL | Contact

Copyright © 1996-2020 The PostgreSQL Global Development Group

https://www.postgresql.org/docs/12/logicaldecoding-explanation.html 2/2