when ‘N’ message length exceeds 256 and client_min_messages = log , psql can not connect to pgpool.

[liujinyang-highgo]

Hi,
I have met an issue：
set client_min_messages = log, and the length of 'N' message from backend exceeds 256, psql can not connect to pgpool,
the error info as below:

psql: error: message contents do not agree with length in message type "N"
message contents do not agree with length in message type "N"
message contents do not agree with length in message type "N"

I check function send_message_to_frontend, and found that the usage of the function snprintf() is incorrect：

current usage as below:
/* message */
thislen = snprintf(msgbuf, MAXMSGBUF, "M%s", edata->message ? edata->message : "missing error text");
thislen = Min(thislen, MAXMSGBUF);
memcpy(data + len, msgbuf, thislen + 1);
len += thislen + 1;

we know, the max actual bytes is written to msgbuf is MAXMSGBUF-1, if edata->message too long, 255 byte would be written to msgbuf, but we get thislen value through "Min(thislen, MAXMSGBUF);" is 256, that not correct.
in fact, the length of msgbuf is MAXMSGBUF+1 , it's value is 257, we allow the max bytes to msgbuf should be 256 , but not 255 ,so we should use snprintf() as below:

thislen = snprintf(msgbuf, MAXMSGBUF+1, "M%s", edata->message ? edata->message : "missing error text");
or
thislen = snprintf(msgbuf, sizeof(msgbuf), "M%s", edata->message ? edata->message : "missing error text");

I have verified that, it is OK.

if necessary , I can afford the patch.

Thanks!

[tatsuo-ishii]

Thanks for the report. We should fix the issue. However your proposal truncates messages > 256.
I think proper fix is to use StringInfo library and eliminate the upper limit MAXMSGBUF and MAXDATA thoroughly.

[liujinyang-highgo]

that's great, thanks!

[tatsuo-ishii]

Here is the patch to fix the issue.

fix_long_notice_message.txt