>Original >From: jie wang <[email protected]> >Date: 2026-04-02 09:13 >To: Ning Sun <[email protected]> >Cc: pgsql-hackers <[email protected]> >Subject: Re: Add ParameterDescription message to libpq frontend long message >types > >Ning Sun <[email protected]> 于2026年4月2日周四 08:52写道： >Hi, > >I'm maintaining a Rust library pgwire to implement postgres wire >protocol in rust. While doing a corner case test, I noticed the >inconsistency for ParameterDescription between backend and frontend. > >The backend allows up to 65535 parameters in a prepared statement. But >when running Describe on the statement, there is a size limit of?30000 >bytes?for ParameterDescription on the frontend. This means we can only >describe statements with at most ~7500 parameters. For statements exceed >the limit, it ends up with error about the message size. > >This patch simply adds ParameterDescription to VALID_LONG_MESSAGE_TYPE >whitelist to remove the cap. > > > > >Hi, > >Based on my understanding, this approach is safe for the following reasons: > >1. The message format is clearly defined and has been properly handled. >2. Similar message types (such as RowDescription) are already allowed to >exceed this limit. >3. No changes have been introduced at the protocol level. > >Thanks! >wang jie
Hi, Ning Sun, wang jie, Thank you very much for your investigation and patch. I have learned a lot about libpq internals from this discussion. The overall interaction architecture is: CLIENTAPP <--> LIBPQ <--> BACKEND. The frontend/backend inconsistency we are discussing happens exactly in this workflow, which I summarize below: 1. The client submits a prepared statement with up to PQ_QUERY_PARAM_MAX_LIMIT (65535) parameters. Libpq accepts this request, which conforms to the official PostgreSQL limit documented in Appendix K, where the maximum number of query parameters is defined as 65535. 2. The backend successfully prepares the statement with the full parameter set without any truncation. 3. When the client retrieves statement metadata via PQdescribePrepared() and similar libpq APIs, the backend returns complete parameter information for all 65535 parameters. The resulting ParameterDescription message totals 262146 bytes. However, libpq enforces a hardcoded 30000-byte limit for any message type outside the VALID_LONG_MESSAGE_TYPE whitelist. Since ParameterDescription (type t) is not whitelisted, this valid oversized message is rejected, resulting in a synchronization loss error. 4. After reviewing the libpq source code, I confirmed that ParameterDescription messages only have two consumption paths: - Debug tracing: pqTraceOutput_ParameterDescription(), which iterates and prints each parameter’s metadata to conn->Pfdebug; - Upper-layer application access: clients consume the metadata through public APIs like PQnparams() and PQparamtype(). Even for the full 65535 parameters, the maximum payload size is only around 256KB. This size is completely safe and manageable, and allowing longer ParameterDescription messages introduces no negative impact on either the debug tracing or application API consumption paths. 5. I have applied, compiled and tested this patch locally. It works as expected and perfectly resolves the frontend-backend inconsistency. Thanks again for your great work! regards, -- ZizhuanLiu (X-MAN) [email protected]
