Вопрос про "разбор битых данных" задают примерно с регулярностью пару раз за релиз ;)Проблема в том, что это в целом достаточно комплексная задача, которую надо делить на части:
1. Определять ситуацию, что данные "битые". Это в ближайшее время появится, можно будет поувешивать все всевозможными проверками, чтобы точно гарантировать общую вменяемость читаемого.
2. Реагировать на провалившиеся проверки. Это сложнее, тут надо думать. Самое тупое решение в лоб - провалившаяся проверка выкидывает exception - дальше вызывавший его код ловит и делает какие-то действия по восстановлению, если сочтет нужным, сам. Например, двигается куда-то по стриму и вызывает парсинг повторно. Варианты автоматизации и реализации таких действий внутри ksy надо продумывать. Очевидные варианты типа "сдвинуться на +1, +n, (+n) % m байт и попробовать заново" в принципе можно описать, но иногда бывают и куда более хитрые алгоритмы восстановления, синхронизации и realingment. Например, с откатом назад и особенно противно - с полноценным backtracking, когда надо перепарсить все на несколько уровней вверх, приняв альтернативную парадигму.
Я бы на вашем месте попробовал - вызывать парсинг по кусочкам по идее несложно, никто ж не требует прямо одним вызовом все сделать на автомате. Ресинхронизацию и пропуск при exception'е сделать во внешней вызывающей программе по идее должно быть не так сложно, если я правильно понимаю схему бинарного лога PgSql. В самом крайнем случае никто не мешает взять сгенерированный код и что-то в нем поправить руками. Все лучше, чем совсем вслепую копаться по старинке, без автоматической визуализации и т.д.
