Обсуждение: Logical decoding

 

Well, it depends on what level you're looking at.

Data is read using the xlogreader and fed into the decoding system by the walsender (when using a logical slot) and the SQL level pg_logical_slot_[get|peek]_changes functions. See XLogSendLogical() as called by WalSndLoop() and see pg_logical_slot_get_changes_guts() .

WAL records are passed through to logical decoding and depending on the xlog entry type the reorder buffer and/or snapshot builder. Then when a transaction commit is detected the registered output plugin is invoked and its callbacks are used to process the buffered transaction.

 

There's no "polling thread", but that's probably the closer of the two. A walsender using a logical slot reads WAL as it becomes available. It sleeps on a latch if it runs out of WAL to read and is woken when there's more. It isn't dumped to some special table, it's managed by the reorder buffer infrastructure which uses its own special data structures. Reading may lag behind WAL generation since it's "pulled" by the client and happens lazily after commit.

 

src/backend/replication/logical/*

src/backend/replication/walsender.c

src/backend/access/transam/xlogreader.c

src/include/access/xlogreader.h

src/include/replication/output_plugin.h

contrib/test_decoding/

doc/src/sgml/logicaldecoding.sgml