anchor.diff:  Now, if change event consumers receive that placeholder value,
   the question arises how they should react to this.
   
  -One way, and certainly the easiest from a consumer's perspective, is to avoid the situation in the first place.
  +One way, and *certainly the easiest* from a consumer's perspective, is to avoid the situation in the first place.
   This can be achieved by using a "replica identity" of `FULL` for the Postgres table in question.
   Alternatively, the replica identity can be based on an index which comprises the TOAST-able column.
   
  
positive.code: No, TOAST!
  
  So what's that?
  https://www.postgresql.org/docs/current/storage-toast.html[TOAST] (The Oversized-Attribute Storage Technique) is a mechanism in Postgres which allows to store large column values in multiple physical rows, circumventing the page size limit of 8 KB.
  
  ++++
  <div class="imageblock centered-image">
  
negative.code: put the value back into change events with the marker value.
  
  Debezium makes sure that all change events for one particular record always go into the same partition,
  so they they will be processed in the exact same order as they were created.
  This ensures that the latest value is available in the statestore when receiving a change event with the marker value.
  
  https://kafka.apache.org/documentation/streams/[Kafka Streams] with its state store API comes in very handy for building such a service.
  