Craig Ringer

To reduce the likeihood of tripping this bug, PgJDBC doesn't queue batches that return result sets, such as a `PreparedStatement` that requests generated keys, per issue #195. One possible option...

An alternative to completely changing the data exchange mechanism is to instead get PgJDBC to manage its _send buffer_ properly. PgJDBC currently ignores its send buffer and tries to manage...

Agreed that it's not resolved. I looked into using a separate thread, but couldn't find much clarity on how threads interact with JDBC drivers and what the rules are there....

Ah, it was related to the work I did here https://stackoverflow.com/q/8514725/398670 .

I increasingly think I need to find the time to make PgJDBC use separate threads for tx and rx so the method-caller's thread can retain control. PgJDBC can then wait...

Actually, we can probably break the deadlock by using `Socket.setSoTimeout(int timeout)`. A whole lot of blocking calls would need wrapping, so it might make sense to start by doing this...

Moving to jsonb is wise. I'd like to find the time to test and merge this. It'd be a huge help if you could prepare a test script we could...

`char(1)` isn't any smaller, that's a misunderstanding. If you want a compact 1-byte field you would need to use the data type `bpchar` or `"char"` (note the quotes). Whether it...

> If you delete the conflict history on each node you actually generated a delete/delete conflict Hm. We don't replicate inserts into the conflict history table from the conflict tracking...

It sounds like we need to reproduce this and fix the underlying bug with desynchronized time causing failure to resolve. @gilesw Can you supply a more detailed set of steps...