Hello, I would like to suggest a little more control over the maximum message length, implemented here. https://github.com/jackc/pgx/discussions/1836. Firstly, previous fix does not take into account the possibility of receiving messages with an incorrect specified length from the server, and secondly, using the method for Frontend and Backend messages will not allow them to be applied to the use of the pgx library.
I propose a PR that solves these two problems. https://github.com/jackc/pgx/pull/2138.
Note: The problem is not abstract and is reproduced in practice. Specifically, when updating the major version of the postgres in Spilo (used in Postgres Operator), rsync is launched on port 5432, which responds with messages prefixed with @RSYN. The library interprets this as a message with a length of 1381194062 and allocates a buffer of about 1GB.
Hello, I would like to suggest a little more control over the maximum message length, implemented here. https://github.com/jackc/pgx/discussions/1836. Firstly, previous fix does not take into account the possibility of receiving messages with an incorrect specified length from the server, and secondly, using the method for Frontend and Backend messages will not allow them to be applied to the use of the pgx library. I propose a PR that solves these two problems. https://github.com/jackc/pgx/pull/2138. Note: The problem is not abstract and is reproduced in practice. Specifically, when updating the major version of the postgres in Spilo (used in Postgres Operator), rsync is launched on port 5432, which responds with messages prefixed with
@RSYN
. The library interprets this as a message with a length of 1381194062 and allocates a buffer of about 1GB.