Sam Stokes

Unfortunately right now `--on-error` only applies to errors that occur in the client daemon. That error is coming from the logical decoding output plugin, which currently always terminates the replication...

Hmm, that nabble link has been down for maintenance since yesterday so I can't read the thread you linked to. Does look like there might be an extra case to...

This seems related to the proposal in #54 to have messages include a "type" field that would explicitly distinguish inserts, updates and deletes: i.e. instead of `{"value": "hello"}`, you'd get...

As of PR #114 (just merged) we now represent NUMERIC as a double. That's not ideal, as it could lose precision, therefore leaving this issue open; but it's better than...

Documenting current behaviour: - if the length in bytes of an _encoded message_ (depending on the `--output-format`) exceeds Kafka's `messages.max.bytes`, the broker will refuse the message. If the Bottled Water...

> I'm pretty tempted to just truncate large values in the extension Unfortunately I wasn't thinking clearly when I wrote this. Large values could be strings or byte arrays, but...

@uhoh-itsmaciek we could if we changed the framing protocol to have a "packet switched" semantics. Currently each frame contains an entire row, encoded as an Avro record. (Frames themselves are...

I've submitted PR #115 which offers a mitigation: if running the client with the `--on-error=log` policy, it will also configure the initial snapshot and replication output plugin to run with...

It should work without issue, although it will probably require some minor build changes (possibly due to changes in Postgres development headers, definitely because the extension will need to be...

@kinghuang that's an interesting use case. Roughly how big (bytes or rows) is that table? Is the primary key an autoincrementing integer, or are you using a timestamp as the...