On Thu, Sep 28, 2023 at 11:01:14AM +0200, Jakub Wartak wrote: > v3 attached. I had a problem coming out with a better error message, > so suggestions are welcome. The cast still needs to be present as per > above suggestion as 3GB is still valid buf size and still was causing > integer overflow. We just throw an error on >= 4GB with v3.
+/* Safety net to prevent requesting huge memory by each query to pg_stat_activity */ +#define PGSTAT_MAX_ACTIVITY_BUF_SIZE 4 * 1024 * 1024 * 1024L - size = add_size(size, - mul_size(pgstat_track_activity_query_size, NumBackendStatSlots)); + pgstat_track_size = mul_size(pgstat_track_activity_query_size, + NumBackendStatSlots); + if(pgstat_track_size >= PGSTAT_MAX_ACTIVITY_BUF_SIZE) + elog(FATAL, "too big Backend Activity Buffer allocation of %zu bytes", pgstat_track_size); + size = add_size(size, pgstat_track_size); That should be enough to put in a hardcoded 4GB safety limit, while mul_size() detects it at a higher range. Note, however, that elog() is only used for internal errors that users should never face, but this one can come from a misconfiguration. This would be better as an ereport(), with ERRCODE_CONFIG_FILE_ERROR as errcode, I guess. "Backend Activity Buffer" is the name of the internal struct. Sure, it shows up on the system views for shmem, but I wouldn't use this term in a user-facing error message. Perhaps something like "size requested for backend status is out of range" would be cleaner. Other ideas are welcome. -- Michael
signature.asc
Description: PGP signature
