Generally when a transaction commits in PostgreSQL, then immediately the logical decoding process will start and convert the WAL data into steam of data for consumers. My understanding is

Commit » WAL » Decode process » Publication to filter the tables » Slots to store the data

What I'm trying to understand is:

  1. Decode process - This will decode the WAL whether your consumer is up or down, just decode and push it to Slots. OR if this is wrong, then PostgreSQL will not do decode and wait until the consumer will up.
  2. Slots are the storage area that holds the decoded data OR it'll just maintain the state.
  3. Decode process - I have enabled logical replication for a specific table. But on the other table, I did a bulk commit. This change also should be part of the decode process, it'll decode the data and then it'll check on the publication. If the table is not there, then simply leave it and decode the next event. Is it correct?

1 Answer 1


I did a PoC to simulate this scenario. Got the answer to all of my questions.

  1. The decoding process will only kick when the consumer(subscription is active)
  2. Slots - Maintain the sync metadata with LSN and once the consumer is active, start steaming the decoded data to the consumer.(Yes it'll hold the decoded data as disk spills)
  3. Decode process will decode the complete WAL and if the matching table is found then send it to the slot else skip that event. But decoding will happen for the entire WAL.

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.