Anton Duyun

We've faced that issue too and I believe I have a fix for that [here](https://github.com/Squiry/async-http-client/commit/40e3666d1283f2d630d4d1f7c8a0a2efcad133ee). @rossabaker Your reproducer is not there anymore, can you check that commit please?

Well the limit is 65_536 so it does look like some postgres limitation and the message you see is the actual backend message. I don't think that we should validate...

> I couldn't find a documented limit on the postgres side Yeah, I tried to find something too but I've found only some stackoverflow posts. So I've just tried some...

Yeah, spring with `NamedJdbcTemplate` kind of spoiled us all with that `?` joining for java `List`.

This fix does work in my case. I will create a PR, but I'm not sure about state of this project tbh.

@fzoli You can call any of those functions without driver's explicit support. Take a look [here](https://gist.github.com/Squiry/57e1801fadcdea8294579abd51f033ac). But there's one bad thing in reading: backend will send data by 65536 bytes...

I think AsyncHttpClient uses nettie's http codec. Take a look at `io.netty.handler.codec.http.HttpClientCodec`, but it's api is not as simple as `parse byte array` ofc.

Is it the only error in logs? We kind of have leak in `BackendMessageSubscriber.addConversation` on `if (!isConnected.get())` branch so there, since we are releasing encoded parameters only on encoding part....

IIRC netty 5 has another interface for buffers, so we will have to rewrite like the whole encoding/decoding layer, so no, it doesn't sound as a drop in replacement yet...

> I'd like to understand where the disparity between 256/512-bit and 128-bit vectors comes from The way I've implement that feature for 128bit is not the same as the arm64...