On 9 July 2016 at 01:57, Joshua Bay <joshuaba...@gmail.com> wrote:

> where are the entry points to 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.

> Specifically, we want to know whether logical decoding happens immediately
> after commit, or whether there is a polling thread that scans the Write
> Ahead Log and then dumps to the special table?

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.

> and where are this code is in the codebase?


 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to